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ABSTRACT 


The Army and Air Force have interest in the development of a Joint Precision 
Aerial Delivery System (IPADS) that could remotely and accurately resupply dispersed 
and geographically isolated ground forces. The Marine Corps has requested options that 
offer increased accuracy, lighter payloads, greater stand-off distances and reduced cost. 
To date, most research has resulted in a series of large, expensive and platform-specific 
solutions, which do not capitalize on the enhanced range and capability afforded by 
existing and commercially available unmanned aerial system technology. The systems 
engineering processes contained in the conceptual and preliminary design phases 
are utilized to investigate and develop a potentially low-cost alternative to existing 
systems. Using an Agile methodology, individual components are designed and 
incorporated into an integrated aerial system that utilizes an autonomously guided and 
controlled ram-air parachute delivered from an unmanned aerial platform. 
Employment of the low-cost micro-light weight class of JPADS has the potential 
to provide all services with a near-term platform to remotely deliver diverse 
logistical and sensor payloads while minimizing risk to forces. 
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EXECUTIVE SUMMARY 


Aerial delivery systems (ADSs) have a well-documented history of affecting the 
military battlefield at both the strategic and operational levels for the better part of the 
last century, and recent technological advances have facilitated an extraordinary increase 
in the precision and accuracy of these systems. The range of payload sizes and weights 
has continued to expand, as have demands for increased accuracy and reliability 
associated with delivery. Technological advancements in ram-air parachute design, 
unmanned aerial vehicles (UAVs) and inertial navigation systems (INSs) continue to 
generate expanded interest by the United States Marine Corps (USMC) in bringing 
smaller payload sizes, and their associated capabilities, to the modem tactical battlefield. 
This research applies a systems engineering approach to design a prototype micro-light 
weight class precision aerial delivery system (PADS) to determine whether low-cost, 
commercial-off-the-shelf (COTS) navigation components can provide sufficient accuracy 
and reliability to close the capability gap between the systems currently in operation and 
the combat operational need for rapid-response, tactical logistical resupply in austere and 
dispersed locations. 

In order to address the primary research question, a brief summary on the history 
of PADSs and descriptions of the general classes are included. The aerodynamic 
fundamentals of ram air parachutes are briefly discussed, and an introduction to the 
terminology used in the development and testing of PADSs is provided. Previous Naval 
Postgraduate School (NPS) research in the development of the Blizzard autonomous 
aerial delivery system (AADS), as well as methods for updating and enhancing PADS 
navigational accuracy are presented. The standard measures of performance (MOPs) and 
measures of effectiveness (MOEs) used for the development of PADSs are described, as 
well as the application of the Agile methodology in systems engineering. Several 
potential additional PADS mission areas also are summarized. 

The application of traditional and Agile system engineering methodologies is 
explained, including the various technical activities associated with the conceptual and 
preliminary design phases. The core problem that PADSs are designed to resolve is 



identified, and subsequently, the basic PADS functions are listed for both operational and 
experimental settings. The needs, wants and concerns of several stakeholders are detailed, 
as well as the design criteria that influenced conceptual design. Points of contrast 
between operational and experimental system design criteria are highlighted. Several 
architecture decisions are described including the influence of shifting design 
considerations on the architectural evolution. The operational concept for employment of 
PADSs is discussed and a functional analysis is specified. 

Subsequently, the conceptual and preliminary design of a Snowflake ADS and 
several additional components of the Blizzard AADS are described. The specifications 
for the two types of UAVs that were utilized in flight-testing are included. Several 
iterations and a final prototype design are summarized, including the installation and 
usage of two types of commercial-off-the-shelf (COTS) available autopilot computers. A 
description of the final design for a power distribution sub-system is detailed, as early 
iterations contributed to unexpected failures in testing and experimentation. A description 
of each type of ram air parachute is included, as well as the three types of 
UAV/Snowflake separation sequences. A comparison between the flight control 
dynamics of fixed-wing platforms and a ram air parachute platform is incorporated, as it 
proved to be a significant challenge in the implementation of COTS technology. 

A comprehensive summary of 65 flight tests over a nearly ten-month period, and 
several simulations conducted in the Aerodynamic Deceleration Systems Center (ADSC) 
laboratory at NFS are included. The results from the flight tests are correlated with 
sequential improvements in the parachute deployment methods that were derived from 
failure mode analysis. Additionally, the ability of each autopilot to capture and retain 
valid experimental data is described, as it directly influenced the author’s conversion 
from the original flight computer to a second type. Various lab simulations and the 
mathematics used to convert recorded data to a more useful coordinate frame using 
quaternions are detailed. Subsequently, a representative flight profile is described and 
illustrated to facilitate follow-on control system development. 


XX 



In summary, the application of systems engineering methodology to influence 
conceptual and preliminary design is described in detail and utilized throughout prototype 
design. While full operational capability was not realized during the course of this 
research, several conclusions were identified, including the potential for follow-on 
improvements in design. Low-cost, COTS navigation components are likely to provide 
sufficient accuracy and reliability to close the capability gap between the PADSs 
currently in operation and the combat operational need for rapid-response, tactical 
logistical resupply in austere and dispersed locations. However, continued research is 
warranted to determine whether performance and reliability requirements can be 
delivered in a low-cost manner. 
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I. 


INTRODUCTION 


A. BACKGROUND 

Aerial delivery systems (ADSs) have a well-documented history of affecting the 
military battlefield at both the strategic and operational levels for the better part of the 
last century, and recent technological advances have facilitated an extraordinary increase 
in the precision and accuracy of these systems. The range of payload sizes and weights 
has continued to expand, as have demands for increased accuracy and reliability 
associated with delivery. Early precision aerial delivery systems (PADSs) were designed 
and constructed to deliver large payloads for strategic and operational logistical resupply 
with a predetermined accuracy specification. The United States Marine Corps (USMC) 
has stated that “expanded use of unmanned systems for resupply of forward-based units 
is not only viable, it is a critical operational requirement” (United States Marine Corps 
[USMC] 2013, 28). Technological advancements in ram-air parachute design, unmanned 
aerial vehicles (UAV) and inertial navigation systems (INSs) continue to generate 
expanded interest by the USMC in bringing smaller payload sizes, and their associated 
capabilities, to the modem tactical battlefield. 

In response to a current warfighting capability gap in the ability to provide tactical 
logistical support while minimizing risk to forces, the Office of Naval Research (ONR) has 
developed the Autonomous Aerial Cargo/Utility System (AACUS) Innovative Naval 
Prototype (INP) Concept of Operations (CONOPS) with the goal of providing rapid-response 
payload delivery by utilizing advanced autonomous capabilities. ONR expected that 
developed systems should be able to take advantage of unmanned vertical takeoff and 
landing (VTOL) capabilities and provide reliable delivery of medical and logistical supplies 
to geographically dispersed units in austere locations and environments. The AACUS INP 
CONOPS also includes the additional complexity of landing area obstacle detection and 
avoidance, and autonomous landing at unprepared landing sites and the ability for terminal 
users to execute supervisory control without specialized training (Office of Naval Research 
[ONR] 2012,2). 
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Advances in PADSs have potentially merged with the capability shortfalls 
highlighted in the AACUS INP CONOPS and offer a potentially simpler and less 
expensive solution than some of the technologies and solutions envisioned by ONR. 
Focused systems engineering research is warranted in the design and applicability of 
ultra-light PADSs as a potential solution. PADSs have the potential to offer fewer 
complications, reduce exposure to hostile threat, lower cost, and increase range and 
endurance capability. The capability gap summarized by ONR, has been expressed by 
numerous Department of Defense (DOD) entities and can potentially be closed with the 
use of PADSs for significantly lower costs in terms of both financial resources and 
technical complexity. 

B. OBJECTIVES 

The primary objective of this thesis is to utilize a systems engineering approach to 
design a prototype micro-light weight class PADS and to answer the following question: 

• Can low-cost, commercial-off-the-shelf (COTS) navigation components 
provide sufficient accuracy and reliability to close the capability gap 
between the systems currently in operation and the combat operational 
need for rapid-response, tactical logistical resupply in austere and 
dispersed locations? 

Additionally, secondary research questions are 

• What are the operational limitations for employing a micro-light weight 
class PADS? 

• Can various systems engineering methodologies be applied to a research 
area to provide insight and improved functionality during conceptual and 
preliminary design? 

• What are the key differences between a prototype design constructed for 
operational use as compared to a design constructed to support scientific 
experimentation? 

• Does the NPS Systems Engineering curriculum adequately prepare its 
students to work within a multi-discipline engineering team to complete a 
technical thesis, including prototype design, construction and field 
experimentation? 
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C. RESEARCH 

Preliminary research was conducted utilizing open source government 
documentation, discussions with unmanned aerial systems (UAS) and PADS subject 
matter experts, laboratory experimentation and field flight experimentation at McMillan 
Airfield, Camp Roberts, CA. 

The following computational and electronic resources were utilized during 
various phases of this research: 

• APM Planner 2.0: Open source application for configuring, testing and 
calibrating autonomous vehicle control platforms. Specifically, APM 
Planner 2.0 was used with the Pixhawk autopilot in early research and 
flight-testing. 

• Rowley CrossWorks for ARM Version 3: Comprehensive C/C++ 
assembly language development system used for programming, compiling 
and debugging an X-Monkey autopilot. 

• MATLAB 2015B: A high-level language and computational software tool 
used extensively for data analysis of flight parameters and control system 
design. 

D. CURRENT STATE 

The Snowflake ADS, an ongoing research project at the Naval Postgraduate 
School (NPS), started in 2008 and utilizes a series of commercially available sensors that 
integrate data from global positioning systems, three axis accelerometers, three axis 
gyros, a magnetometer and a barometric altimeter. The previous guidance design utilized 
a series of highly developed and specific algorithms that facilitated the guidance and 
control of a two skin rectangular parafoil. Various parafoils could be attached to the 
Snowflake system to facilitate payloads of different sizes. Unfortunately, a good portion 
of the resident Snowflake experts had departed NPS, and a significant number of the 
components required for ongoing experimentation were no longer available. 

1. Capabilities Gap 

The ONR CONOPS highlights the following two capability shortfalls: 
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Executing resupply is significantly challenging due to primarily the lack of 
paved roads coupled with difficult, mountainous terrain which has 
diminished the effectiveness of traditional means of overland logistics 
movement using ground transportation. The Joint Force needs an alternate 
means to provide sustained, time sensitive, logistics support over widely 
dispersed locations. 

Combat in urban environments has shown that moving a casualty can be 
difficult and time consuming. Moving an individual only a few hundred 
yards can take an hour or more. The extended lines of communication 
between forces and their forward operating bases (FOBs) (inclusive of 
Medical Evacuation (MEDEVAC) by aircraft) are at risk of enemy 
ambush or improvised explosive device (lED) attack (ONR 2012, 3). 

The USMC also has requested research and investment in the usage of unmanned 
transportation systems and robotic systems to assist with resupply to the engaged 
warfighter. The goal is tailored delivery while minimizing risk to human life. (USMC 
2013, 30) In general, the USMC has viewed previously developed JPADSs as being too 
large, too heavy, too expensive and not responsive enough to urgent warfighter needs. 

2. Constraints 

The principal constraint of an updated Snowflake ADS is that it must be designed 
to close the current capability gap (or at least a portion of it) to offer increased simplicity, 
reduced exposure to hostile threat and/or reduced cost. The capability gaps described do 
not need to be met in their entirety. As such, PADSs that can close one of the capability 
gaps with significantly enhanced simplicity should not be excluded from consideration 
simply because it does not perform both. The ONR CONOPS indirectly advocates for a 
solution that can be terminally controlled as well as landed and re-launched in the field. 
The updated Snowflake ADS must be able to accomplish the intended delivery 
requirement, and if it can sufficiently deliver payload via autonomous parachute, then the 
complexity of landing and relaunching can be avoided. 

E. DESIRED STATE 

The desired capability resulting from this research is a systems engineering 
approach to conceptual and initial design of a Snowflake ADS to perform small-scale 

logistical resupply in a more efficient manner than existing systems do. The research is 
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designed to examine the capability gaps closely, analyze the effective stakeholder needs 
and design a potential solution to achieve the objective economically. 

F. METHODOLOGY 

This research was conducted in parallel with the effort of Lieutenant Commander 
Matthew O’Brian, from the Naval Postgraduate School (NPS) Undersea Warfare 
Curriculum. As Lieutenant Commander O’Brian conducts research in support of the 
Dynamic Systems and Control Track in the Mechanical Engineering Department, the 
author intended to pair with O’Brian’s research effort by applying a systems engineering 
methodology to maintain a direct link between the research being conducted and 
resolution of a stakeholder need or requirement. Utilizing cross-domain and multi-field 
engineering principles, the author integrated multiple components and disciplines ranging 
from computer programming, electrical engineering, radio frequency communication, 
classic control and aerodynamics. The author’s intent was to conceptually and 
preliminarily design and engineer a complete logistical delivery system which could be 
used to contribute to the battlefield. 

To assist in accomplishing the design and engineering, the author used a hybrid 
systems engineering and analysis approach, with substantial input from Blanchard and 
Fabrycky, as well as an Agile systems engineering methodology used within the PADS 
industry for the design and engineering phases. The Blanchard and Fabrycky methods 
were used to correlate effectively the stakeholder needs from operational users and to 
develop an updated design of the Snowflake ADS while providing traceability. The 
author also used elements of the Agile methodology and design thinking principles to 
provide targeted iteration within the conceptual and initial design phases. 

Though the parallel effort of Lieutenant Commander O’Brian is focused on the 
classical and modem methods of control associated with guidance and navigation of the 
Snowflake ADS, the concepts have been incorporated from conceptual design. The 
Snowflake ADS was designed to capture sufficient data and serve as a platform for 
experimentation to support the development of the various plant models required for 
effective feedback control. 
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G. THESIS ORGANIZATION 


To address the objectives and research questions detailed in section B, this thesis 
is arranged as follows: 

• Chapter II presents a summary of related work. It includes a brief history 
on the development, classification and utility of Joint Precision Air Drop 
Systems (JPADSs), the fundamentals of a ram-air parachute, the 
fundamentals of aerial delivery systems, a description of the Blizzard 
autonomous aerial delivery system (AADS), a summary of two techniques 
used to enhance terminal accuracy, a description of measures of 
effectiveness (MOEs) and measures of performance (MOPs) used to 
assess PADSs and an overview of the Agile methodology as applied to 
systems engineering a PADS 

• The application of systems engineering methodology is covered in 
Chapter III. It includes an overview of conceptual and preliminary design, 
the problem definition and needs identification, a stakeholder analysis, 
design criteria used, the operational concept for PADSs and a functional 
analysis 

• Chapter IV details the design of the Snowflake system components. It 
includes a description of the Arcturus T-20 and JUMP 20 UAVs, overview 
of the Snowflake ADS including the design of the autonomous guidance 
unit (AGU), specifications of the ram-air parachutes used, summary of the 
various parachute deployment sequences and a description of the flight 
control dynamics associated with ram air parachute control 

• Chapter V compiles the Snowflake simulation and test results. It includes 
an analysis of the failure modes encountered during flight 
experimentation, methodology used for conducting coordinate 
transformation and analysis of representative flight test results 

• This thesis ends with Chapter VI, which provides a conclusions and series 
of recommendations. It includes an assessment of the incorporation of 
low-cost technology in the development of a micro-light weight class 
PADS, discussion of the associated operational employment limitations, 
description of the utility of systems engineering methodologies utilized in 
conceptual and preliminary design as well as several technical 
recommendations for potential improvements to the Snowflake ADS. 

In summary, PADSs have been present on the military battlefield for an extended 
period and have been asked to perform traditional logistical supply missions. As warfare 
has evolved, the services have requested PADSs with expanded mission capability 
through increased accuracy, decreased size, longer stand-off ranges and reduced cost. 
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This chapter articulates the primary objective of this thesis, as well as secondary research 
questions that were examined in the course of research and experimentation. 
Additionally, the current and desired end state of the research is addressed. Finally, this 
chapter outlines the methodology used and organization of the thesis to assist the reader. 
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II. RELATED WORK 


A. PREVIOUS RESEARCH 

A significant amount of research has been conducted over the previous 50 years 
in the field of precision aerial delivery, driven largely by advances in controlled gliding 
ram-air parachutes as compared to the uncontrolled round parachutes that preceded 
(Yakimenko 2015,1). Driven by the desire to deliver logistics remotely with increased 
accuracy, dozens of PADSs have been developed, each designed to deliver a diverse 
series of payload sizes. Additionally, new applications have continually been examined 
(Yakimenko 2015, 1). The following summary of related works includes the history and 
development of JPADSs, a basic analysis of a ram-air parachute, a description of a 
previous NPS research endeavor to field an AADS, a series of estimation techniques used 
to refine landing accuracy, a proposed set of MOEs and MOPs used to evaluate PADS 
effectiveness and a description of a systems engineering methodology used to develop 
and field a representative PADS. 

B. JPADS PROGRAM 

The Joint Precision Air Drop System (JPADS) was a United States (U.S.) 
Army/U.S. Air Force program jointly developed to examine potential accuracy 
improvements. The goal of the JPADS program was to develop the capability to deliver 
air cargo anywhere in the world within 24 hours. The U.S. Air Force research effort 
focused on the development of a mission planning system that could aggregate available 
wind data over a drop zone (DZ), forecast expected wind and calculate a calculated air 
release point (CARP). This release point should minimize the landing error of a 
conventional unguided aerial delivery system (ADS) (Yakimenko 2015, 10). 

In conjunction with the mission planning system, the U.S Army concurrently 
expended research effort to develop a series of AGUs as well as representative systems in 
the classes that evolved to those indicated in Table 1. 
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Table 1. JPADS Categories. Adapted from Defense Industry Daily (2016). 


JPADS Weight Class 

Weight Range 

Micro-light weight (ML) 

~5-70 kg (10-150 lb) 

Ultra-light weight 

-100-300 kg (250-700 lb) 

Extra-light weight (XL) 

-300 kg-1.1 tons (700-2,400 lb) 

Light weight (L) 

-2.3-4.5 tons (5,000-10,000 lb) 

Medium weight (M) 

-4.5-19 tons (10,000-42,000 lb) 


In addition to simple logistical delivery, the technology developed though the 
JPADS program has proposed applicability that extends well beyond resupply. In his 
2015 summary of the JPADS program, Yakimenko proposes the following additional 
military and security applications: 

• Provide accurate and flexible stealth supply to special forces teams. 

• Provide navigational guide for team night insertion. 

• Support pathfinder operation. 

• Deploy acoustic sensing equipment into battlefield. 

• Deploy electronic warfare equipment. 

• Deliver leaflets accurately. 

• Deploy nuclear, biological and chemical threat sensors. 

• Provide “just in time” supply of advancing troops (2015, 10-1) 

Additionally, Yakimenko also proposes that PADS capabilities can extend well 
beyond military applications to provide: 

• space items recovery (as a final stage of a multistage system) 

• regular supply of remote locations 
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• humanitarian aid and disaster relief deployment to inaccessible locations 
and unprepared DZs including potential field hospitals, refugee camps and 
United Nations compounds 

• all-weather equipment drop for search and rescue operations 

• equipment supply to first responders in disaster areas 

• equipment delivery into rugged mountain areas 

• sensing equipment and video/radio uplink deployment 

• medical equipment supply 

• precision delivery of buoys and lifeboats at sea (2015, 11) 

C. FUNDAMENTALS OF RAM-AIR PARACHUTES 

In 2015, Steven Lingard presented an updated summary on the fundamental 
design of a ram-air parachute. Lingard stated (2015, 73^) that the ram-air parachute, or 
parafoil, was developed in the early 1960s with the effective design replicating a low- 
aspect wing, constructed entirely with fabric without any rigid supporting structure. 
Additionally, Lingard notes that flexibility inherent in a fabric design facilitated packing 
and airborne deployment, similar to previous drag parachute designs, though the airfoil 
characteristics were more closely related to wings than to basic drag parachutes. When 
viewed from above or below, a basic parafoil has a rectangular shape, but the cross 
section is a series of individual airfoils. The upper surface of the parafoil is joined to the 
bottom surface of the parafoil by a series of flexible fabric ribs, which form cells as 
shown in Figure 1. Lingard added that the leading edge of the wing is kept open to allow 
air to enter and fill the parafoil, yet the trailing edge is sealed to retain inflation. There is 
typically a series of apertures cut into the ribs to facilitate the flow of air between cells 
during inflation and the equalization of pressure between cells once the parafoil is 
inflated. 

Lingard continues (2015, 74) that to preserve the basic airfoil shape in the bottom 
surface, there is a series of suspension lines fastened at various intervals along the ribs 
between cells. A rib with suspension lines becomes a loaded rib, and a non-loaded rib is 
one without suspension lines. Non-loaded ribs serve to separate each parafoil cell into 
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semi-cells as shown in Figure 1. These suspension lines are typically cascaded into 
primary suspension lines to reduce the overall drag for the parafoil system. Stabilizer 
panels can be added to the edges of the parafoil to assist in directional stability by 
channeling the flow of air along the parafoil rather than around the wingtip which creates 
a more unpredictable vortex. 



Figure 1. Basic Ram-Air Parachute. Source: Lingard (2015). 


Unfortunately, the drag associated with the suspension lines becomes a significant 
factor as the size of the parafoil is increased. As a result, the drag of the parafoil cannot be 
considered by itself Instead, a systems perspective is needed, where parafoil drag is one 
contributor to the overall system, which also includes the drag of the suspension lines. In 
order to preserve the basic flying qualities of the parafoil and to reduce the length of the 
suspension lines, the ram-air wing is given an arc anhedral, which is also referred to as the 
crown rigging (2015, 84). The amount of anhedral (s) is a function of the line length (R) 
and the span of the parafoil (b). The comparison between the dihedral angle of a 
conventional wing and the anhedral angle of a ram-air wing is shown in Figure 2. 
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Figure 2. Contrast of Conventional Wing Dihehdral and Ram-Air Wing 

Anhedral. Adapted from Lingard (2015). 


Lingard (2015, 92) also proposes the following model to simplify the basic forces 
acting on a parafoil system in flight. The free body diagram shown in Figure 3 
graphically describes the relationship of the various forces acting on the components of 
the parafoil system. In this diagram, each component has a drag, lift and weight force, 
with the exception of the suspension line weight, which is considered negligible. The 
velocity shown (V) represents velocity through the air mass. Obviously, taking 
dynamically changing wind velocity into account creates a much more complex series of 
relationships. The glide angle (y) is the angle between the parafoil velocity vector and the 
horizontal as show in Figure 3. 


13 





L, 



Figure 3. Ram-Air Parachute in Steady State Gliding Flight. Adapted from 

Lingard (2015). 


To maintain effective lateral control of a ram-air parachute, Lingard (2015, 119) 
described the concept of trailing edge deflection with some relative approximations for 
the yawing moment that could be generated by asymmetric trailing edge deflection. The 
yaw rate, in radians per second, can be determined using the following expression: 

F 

r = 0.71-5. 

where V denotes the airspeed, b denotes the span of the ram-air parachute and 5^ denotes 
the amount of asymmetric trailing edge deflection in radians per second. 

D. FUNDAMENTALS OF AERIAL DELIVERY SYSTEMS 

To standardize the relationships between various factors considered during the 
execution of a precision aerial delivery (PAD) mission. Brown and Benney (2005, 4) 
defined the following terms, each of which is illustrated in Figure 4: 

• Impact point (IP): designated point of intended landing 

• Point of impact (PI): actual point of landing 
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• Air release point (ARP): point of release of the airdrop unit from the drop 
aircraft 

• Ballistic trajectory: trajectory along which an unguided, drag-only body 
would fall in order to reach the IP 

• Ballistic ARP: the intersection of the delivery aircraft flight path with the 
ballistic trajectory, i.e., a theoretically perfect release point 

• CARP: Standard airdrop terminology for the calculated location of the 
ARP based on estimated winds 

• Air release circle (ARC): a circle at the release altitude, centered on the 
Ballistic ARP, within the glide performance of the system is sufficient to 
reach the IP. 



Figure 4. Terms Associated with Aerial Delivery Systems. Source: Brown 

and Benney (2005). 

The location of the CARP becomes significant when the wind estimation contains 
error, which is likely, or when there are multiple drops intended for the same IPs. To 
ensure safe separation of PADSs, the delivering platform will incorporate some time 
between successive PADS release, which will correspond to a positional displacement 
requiring compensation during the PADS’s flight and navigation profile. 
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E. BLIZZARD AADS 

In 2008, a coordinated effort between U.S. Special Operations Command 
(SOCOM) and the NPS Aerodynamic Deceleration Systems Center (ADSC) conducted 
research to design a system for ultra-light-weight precision aerial delivery. Researchers 
from NPS and the University of Alabama presented a miniature prototype, termed the 
Blizzard AADS, which utilized an inertial trajectory and an estimate of surface winds to 
compute a final standard-approach-pattem and landing maneuver into the wind. Accuracy 
results from the Blizzard AADS were inside of 10m CEP (Yakimenko et al. 2011, 1-2). 

The Blizzard AADS consisted of a four major components: the T-20 unmanned 
aerial vehicle, the Snowflake ADS, a ground mission command and control center 
(MCCC), and an optional ground target weather station. The MCCC facilitated the entry 
of target coordinates; the weather station allowed updated target area winds to be used for 
landing accuracy improvements and the T-20 delivered the payload to a pre-determined 
launch location. The Snowflake ADS was a small 4”x8”xl0” payload container 
consisting of avionics and control actuators, including a global positioning system (GPS) 
receiver, three-axis accelerometers, gyroscopes, a magnetometer and a barometric 
altimeter (Yakimenko et al. 2011, 2-4). 

The Blizzard AADS proved to be a nearly complete fielded system, useful for 
follow-on research and concept exploration. The research proved the accuracy of the 
system and showed that enhancements and subsequent examination of additional 
applications were possible. 

F. POSE ESTIMATION AND MONOCULAR AUGMENTATION 

In his Ph.D. dissertation, Hewgley (2014, v) provides two methods to aid in 
enhancing PADS accuracy. In an effort to better estimate the winds between a descending 
ADS and the intended point of landing (POI), Hewgley assumes a logarithmic 
relationship between the air mass height and the horizontal wind velocity. The estimation 
technique facilitates a better estimation of the PADS’s computation of terminal winds and 
the computation of a landing trajectory. 
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Utilizing the previously described Snowflake ADS as an experimentation 
platform, Hewgley developed a method wherein the Snowflake measured real-time wind 
speed and direction aloft, utilized a logarithmic model of boundary layer winds near the 
surface and continually computed the wind direction and speed that it would fall through 
during the remainder of the descent. This method, summarized in Figure 5, was 
particularly suited for shipboard and maritime usage in which the course and speed of the 
ship can be adjusted to produce a relatively predictable wind (Hewgley 2014, xxiii). 



Figure 5. Logarithmic Wing Estimation Used for Planning Intended Landing 

Point. Adapted from Hewgley (2014). 

Additionally, to assist in target motion estimation, Hewgley opted to utilize a 
monocular vision camera. The monocular system was selected for simplicity and a cost 
reduction. By using a simple geometric projection, a homogeneous coordinate 
transformation and a subsequent state-space formulation, the Snowflake ADS utilized its 
monocular sensor to provide navigation adjustments based on relative motion between 
the sensor and the target (Hewgley 2014, 45). Additionally, Hewgley provides an 
unscented Kalman filter (UKF) algorithm to blend the target in-target and out-of-target 
measurement error covariance matrices as a monocular sensor is unlikely to retain the 
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target within view due to the pendulum oscillations caused by the descending ram-air 
parachute (Hewgley 2014, 90-91). 

G. MEASURES OF PERFORMANCE AND EFFECTIVNESS 

Three critical operational issues (COIs) were created to guide the development of 
JPADSs in the mid-2000s, which were subsequently used during a Joint Military Utility 
Assessment (JMUA) of existing technologies. They were 

• COI 1. Does the IPADS system-of-systems successfully support payload 
delivery at the target weights and standoff distances in its intended 
operational environment? 

• COI 2. Does the IPADS system-of-systems provide the Joint Task Force 
(JTF) Commander with an enhanced operational capability? 

• COI 3. Is the IPADS system-of-systems suitable for employment in its 
intended environments? (Benney et al. 2005a, 11) 

1. System Reliability and Accuracy 

PADS accuracy was described in detail by Brown and Benney (2005, 3). System 
reliability was defined as the probability of a PADS successfully reaching a location near 
the DZ from which a successful guided approach and landing at the intended IP could be 
achieved. Terminal accuracy was the distance from IP to the nearest of all landing points 
that fall within a specified probability level. Overall system accuracy was defined as the 
distance from the IP to the nearest of all landing points landing within a specified 
probability level. These relationships are summarized in Figure 6, with the significant 
distinction that an unreliable system is still characterized as a valid, though inaccurate 
system. 
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Figure 6. Relationship Between System Accuracy, Reliability and Terminal 
Accuracy. Adapted from Brown and Benney (2005). 


2. Reliability: Failure Modes and Effects 

In 2015, expanding the definitions set by Brown and Benney, Yakimenko 
characterized five potential failure modes that could affect the reliability of the PADS as 
follows: 

• air carrier missing CARP (which is especially critical for unguided ADSs 
or PADSs with very limited control authority) 

• parachute failure to open (can include several submodes depending on the 
number of PADS stages) 

• parachute or control line damage 

• failure of the AGU to operate properly 

• excessive actual winds aloft (compared to predicted) precluding reaching 
the DZ even if ever 5 dhing works correctly (2015, 14) 

H. AGILE METHODOLOGY 

In addition to simply developing and advancing the capabilities of PADSs, 
significant advances have been made in the utilization of Agile development 
methodologies and their utility in executing systems engineering through the 
development of parachute systems. In 2011, Barber et al. discussed their use of an Agile 
methodology as an alternative to the conventional Plan Driven Product Development Life 
cycles (PD-PDLC), or “waterfall” development shown in Figure 7. They advocated the 
three essential Agile values that made it unique: 
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• Requirements are too important to be left to the beginning. They must 
evolve with user interaction and interpretation as the implications come 
into view. 

• Planning and documenting is important, but following the plan 
documenting details is not as important as satisfying the customer with a 
solution that works correctly. 

• The systems engineering and management processes emerge to fit the 
circumstances and control metrics are empirically determined. The 
methodology does not specify this ahead of time. (Barber et al. 2011, 2) 



Figure 7. PD-PLDC “Waterfall” Methodology. Source: Barber, Montague 

and Barello (2011). 


Barber et al. advocated that an Agile methodology was most effective when the 
following conditions exist: 

• Requirements are unstable or evolving. 

• All stakeholders (customers, managers, developers, testers) are in a 
position to collaborate as requirements evolve. 

• Technical innovation is essential to achieve required capability. For some 
programs, innovation is not just “bonus” from clever engineers, but an 
outright necessity for the success of the effort. (Barber et al. 2011, 2) 

Usage of Agile methodology, shown in Figure 8, has proven successful in the 
production of some PADSs, especially when the level of engineering effort and 
complexity require it. Barber et al. stated that adjusting requirements, iterated delivery 
and face-to-face interaction was a superior method for system engineering, and the idea is 
sound. The Agile methodology can be applicable to projects of a certain size and 
technical complexity, though it offers no increased guarantee of delivering a product on 
time and on budget when compared to the typical DOD Acquisition Framework. 
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Lastly, Barber et al. discussed the architecture decisions made through the 
development of their JPADS design. They stated: 

Good architecture also supports cost-effective development, not just the 
resulting design. Top level architecture decisions evident in the resulting 
JPADS design include: 


• common User Interface across platforms (LCD Screen, Mission Planning, 
Rigging etc.) 

• common Avionics and flight software across all platforms 

• open Source Operating System 

• flight software extensible to new canopy designs and control techniques 

• suspended-type AGU 

• tool-less connections between parachute and AGU 

• easy software upgrade 

• easy access to flight log data 

• common canopy structural and planform features to maximize 
commonality and simplicity of packing and rigging (Barber et al. 2011, 9) 
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Figure 8. Airborne Systems Agile Methodology for U.S. DOD Programs. 

Source: Barber, Montague and Barello (2011). 
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I. SUMMARY 

This chapter summarized some of the recent research relevant to the development 
of PADSs, including weight class definitions and the history of the JPADS program. This 
chapter also described the potential applicability of PADSs beyond logistical resupply to 
additional mission areas. The aerodynamic fundamentals of ram air parachutes were 
briefly discussed, as well as an introduction to the terminology used in the development 
and testing of PADSs. Subsequently, previous NPS research in the development of the 
Blizzard AADS, as well as methods for updating and enhancing PADS navigational 
accuracy were presented. Standard MOPs and MOEs used for the development of PADSs 
were described, as well as a summary on the utility of Agile methodology in systems 
engineering. The author’s application of traditional and Agile systems engineering 
methodologies to design a low-cost micro-light weight PADS are detailed in Chapter III. 
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III. SYSTEMS ENGINEERING METHODOLOGY 


A. CONCEPTUAL AND PRELIMINARY DESIGN OVERVIEW 

Conceptual and preliminary design phases of a systems engineered project have 
several activities and interactions that must be accomplished to ensure the design is 
related to an actual stakeholder need responding to a perceived or actual problem. 
Blanchard and Fabrycky highlight several of these steps shown in Figure 9. This chapter 
will focus on several activities within these phases that assisted in the design and 
development of several prototype micro-light weight class PADSs, as well as some of the 
architecture decisions made through the design phase of an update to the NPS Snowflake. 
While preliminary design of a micro-light weight class PADS was geared toward 
operational employment, it is essential to note that the author did need to make 
significant deviations from an operational employment scenario to support adequate field 
testing and experimentation. In a sense, the author became the primary stakeholder of the 
preliminary design, as it was designed to support a more successive development that 
would more closely match an operational stakeholder need. 
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Figure 9. Technological Activities and Interactions within the Design 
Phases. Adapted from Blanchard and Fabrycky (2011). 
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B. PROBLEM DEFINITION AND NEED IDENTIFICATION 

Many of the approaches to developing and constructing PADSs of all classes are 
derived from the three core COIs identified earlier. Continued exploration and research 
into other potential mission areas for micro-light weight class PADSs warrants a 
revalidation of the basic problem definition and identification of a hypothetical 
stakeholder’s needs. The core problem surrounding any type of precision aerial delivery 
is that there is a person, unit or organization that needs (or wants) something that it does 
not have. Aerial delivery is more suited for longer ranges between the current location of 
the equipment and its intended location. Additionally, if time is a concern, the speed of 
aerial delivery over extended ranges is preferred over alternative means. 

From a military perspective, the presence of hostile or adverse factors impeding 
delivery is a concern and can make aerial delivery a preferred option. In consideration of 
the hostile factors, the effective need is for delivery with a minimum of risk to the 
delivery method as well as to the intended recipient. For example, if preparation of a 
helicopter-landing zone presented an increased risk to isolated military forces, then the 
forces may well consider whether the logistical supply was necessary. The cost 
associated with larger classes of PADSs have been accompanied by the effective 
requirement that the unit being supplied collect and return the PADS for subsequent 
reuse. 

In addition to the operational utility of employed PADSs, the micro-light weight 
class design engineered for this thesis also presented a secondary set of needs. It needed 
to preserve and retain experimental data, to survive repeated flight experiments, to be 
compatible with available launch platforms and parafoils, and finally, to support the 
development of an ADS that could match or exceed previous designs. 

In summary, the combined problem that users, developers and researchers have is 
that there is the need for a proven, reliable method to distribute rapidly, responsively and 
efficiently physical items from one location to another at potentially medium to long 
ranges while incurring no additional threat from hostile forces. 
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c. 


STAKEHOLDER ANALYSIS 


A more thorough investigation of the applicable stakeholders, their effective 
needs and concerns is shown in Table 2. As the author’s updated version of the 
Snowflake was not designed for a particular customer, the interests of the stakeholders 
represented are generalizations only, based on information collected from various 
unclassified sources, primarily the ONR AACUS CONOPS (ONR 2012, 3^). Various 
humanitarian aid and non-governmental organizations (NGOs) are also potential 
customers interested in the development of micro-light PADSs. Additionally, the author’s 
needs are included with the NPS needs, as it is significant to highlight that successful 
research and development are still required to develop solutions targeting the original 
problem statement. 


Table 2. Micro-Light PADS Stakeholder and Needs Analysis 


Stakeholder 

Type 

Need 

Want 

Concern 

ONR 

Current 

Researeh and 
teehnologieal 
development of 
solutions to long-term 
eapability shortfalls 

Teehnology that ean 
provide benefit and 
utility for additional 
eapability shortfalls 

Solutions are too 
speeifie and fail to 
address the eore 
problem statement 

USMC 

Current 

Dispersal of time 
eritieal logistie support 
to dispersed units 

Autonomous delivery 
and the ability to extraet 
wounded military 
personnel 

Likely operational 
environment ineludes 
hostile threats. PADSs 
must be supporting 
units, not units 
supporting PADSs. 

NPS 

Current 

Suitable platform for 
researeh and 
development 

Low-eost with minimal 
eomplexity and the 
ability to work with 
non-speeialized 
equipment 

Platform and results 
must be easily 
transferrable 

NGO 

Potential 

Rapid dispersal of 
logisties to speeifie 
loeations, 

Long range, 

inexpensive and reliable 

Must be more suitable 
in terms of eost or 
simplieity than existing 
alternatives 

USN 

Potential 

Dispersal of logisties to 
mobile platform 

Rapid, long range 
distribution at sea with 
minimal operational 
impaet 

Must be more suitable 
in terms of eost or 
simplieity than existing 
alternatives 
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D. DESIGN CRITERIA 


In re-designing the Snowflake, the author considered the factors shown in 
Figure 10 contrasted with some of the design considerations required to field the 
operational system shown in Figure 11. The blue design considerations are common 
between the NFS Snowflake and an operationally fielded micro-light PADS. The 
considerations shown in green are unique to an operationally fielded system. Conceptual 
and preliminary system design considerations for a research-focused system in 
development differ from those of an operationally fielded system. More significantly, the 
prioritization of these design considerations, regardless of the system’s objective, evolves 
during development. 



Figure 10. System Design Considerations for Research Focused NFS 
Snowflake. Adapted from Blanchard and Fabrycky (2011). 
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Figure 11. System Design Considerations for Operationally Fielded Micro- 
Light PADSs. Adapted from Blanchard and Fabrycky (2011). 

Table 3 presents the shifting emphasis between a research-focused developmental 
design and the design considerations associated with an evolved system. This fluidity of 
design has potential peril in that the developmental design can begin to migrate away 
from the original problem statement and effective stakeholder needs. 
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Table 3. Contrast of Design Consideration Emphasis During Preliminary 
Design for Research Focused NPS Snowflake and Operationally Fielded 

Micro-Light PADSs 


Design 

Consideration 

Research-Focused NPS Snowflake 

Operationally Fielded Micro-Light 
PADSs 

Flexibility 

Support diverse researeh and testing 
objeetives as they are developed 

Support customer needs and wants as 
they evolve 

Interoperability 

Interoperable with available test 
platforms 

Interoperable with all fielded systems 

Safety 

Controlled environment with trained 

users 

Potentially hostile and adversarial 
environment with minimally trained 
users 

Reliability/ 

Maintainability 

Adequate to support multiple seientifie 
experiments. Failures are expeeted. 

Customer expects high reliability. 

Impact of failure can be catastrophic. 

Teehnieal Feasibility 

Must be aeeomplished by two-person 
team within 6-9 months 

Greater opportunity for technical 
advancement and solutions 

Consisteney 

Consistent data eolleetion is paramount 
in development 

Consistent performance is paramount in 
operation 

Supportability 

Limited support during testing at Camp 
Roberts 

Potential requirement to be supported 
in austere locations 

Human Faetors 

Only 1-2 speeialized operators 

Must be able to work with 5-95% 
percentile operator 

Maintainability 

Must be able to eonduet multiple 
experiments in short period of time 

Potential to be single use only 

Affordability/ 

Profitability 

Researeh budget with no speeialized 
equipment 

Potential economy of scale, but 
profitability is significantly weighted 
priority 

Funetionality 

Flexible for various experiments 

Flexible for various missions 

Produeibility 

Short timeline with minimal speeialized 
equipment 

Production costs are concern, but 
unknown in development 

Produet Quality 

Not a eoneern 

Customer demands high and consistent 
product quality 

Reeyelability/ 

Disposability 

Not a eoneern 

Potential to be a significant concern as 
the units may not be recovered 

Environmental 

Sustainability 

Not a eoneern 

Warrants significant attention based on 
customer needs 

Soeial/Politieal 

Feasibility 

Not a eoneern 

Warrants significant attention based on 
customer needs 


The author’s initial design considerations matched those of the operationally 
fielded design but migrated as the objectives and effective stakeholder needs evolved. 
Effectively, the author became the primary stakeholder, with successful thesis completion 
emerging as the primary problem statement. To support this objective, the emphasis on 
data collection and failure mode correction emerged as paramount. 
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E. ARCHITECTURE DECISIONS 


As the emphasis for design considerations evolved during the conceptual and 
preliminary phases, the architecture was designed to incorporate a high degree of 
flexibility, modularity, maintainability and consistency. Since flight experimentation for 
the NPS Snowflake needed to be completed in one-to-two day periods of data collection 
and initial designs exhibited low component experimental survivability, the author 
emphasized modularity within the design. As guidance computers, control actuators, 
parachutes and telemetry components frequently did not survive even the reduced impact 
forces at landing, the design prioritized the ability to replace damaged components with a 
minimal amount of down time. Additionally, there were several ram-air parachute 
designs that would be tested, so the design incorporated the modular concept to facilitate 
parachutes that could readily be transferred and repacked in the field. 

In addition to the high degree of component modularity, initial designs required 
an architecture that could support flexibility. Prototype systems are likely to change 
significantly and eventually converge on a preferred design. Working with a limited 
timeline and budget, the author desired a flexible architecture that could support multiple 
design changes and adaptations. 

F. OPERATIONAL CONCEPT 

The operational concept for employment of precision airdrop combat delivery 
missions is shown in the Department of Defense Architecture Framework (DODAF) 
Operational View (OV) shown in Figure 12. This does not represent all of the potential 
uses for PADSs, as it is specific for a combat logistical delivery over land. However, the 
core concept is that there is a demand to deliver something to a remote location, within a 
certain threshold for accuracy. The exact composition of the payload and the intended 
coordinates are transmitted to a command and control node along with an aggregated 
weather and winds estimate to compute an optimized CARP. In general, PADSs can vary 
from supporting long-term strategic objectives to supporting small-scale urgent resupply 
to troops in contact. Additionally, though the OV-1 depicts a large fixed-wing cargo 
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aircraft, the operational concept is equally valid for all types of aerial delivery platforms, 
including UASs. 



Comm 


GPS 


Communications/Data Paths 

■ ■■■■• Position Feedback 

(upon impact vnth ground) 

GPS Position Data 
• •■■■a C2/Wx/Drop Zone Data 


Airdropped 

Payloads 


Figure 12. Precision Airdrop Combat Delivery Missions (OV-1). Source: 

Benney et al. (2005b). 


G. FUNCTIONAL ANALYSIS 

Blanchard and Fabrycky state that functional analysis in the early conceptual and 
preliminary design phases allows the engineer to generate detailed design criteria, as well 
as to identify the resources required. (2011, 86) With consideration to the complexity of a 
prototype PADS, the author derived and continually adjusted a functional hierarchy and 
the associated descriptions of the functions. 
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1. Functional Hierarchy 

A functional analysis was performed by the author to decompose the mission of 
preforming the aerial resupply mission. The author’s intent was to decompose the core 
functions required to complete the mission. Along with the core mission functional 
hierarchy shown in Figure 13, the secondary mission of performing design 
experimentation is evident. Initial PADS prototypes were constructed to perform the core 
mission, but significant adjustments were required to support design development and 
testing. The additional functions, shown in green in Figure 13, were unique functions 
incorporated into the Snowflake ADS simply to support development, but the author did 
feel it was significant to highlight the degree to which initial designs effectively had 
missions of their own. These functions were derived from design requirements that were 
generated through discovery during testing. 

Application of the systems engineering methodology through functional analysis 
proved extremely useful. Rather than focus on component specific solutions to problems 
encountered during development, the author frequently returned to the first and second 
level functional decomposition to determine the root function being performed. This 
functional analysis was effective in focusing the design effort toward the what needed to be 
accomplished, versus the how it was to be achieved (Blanchard and Fabrycky 2011, 86). 
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Figure 13. Functional Hierarchy of Two PADS Missions 
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2. Description of Functions 

Each of the functions that the PADS was designed to perform is described in 
Table 4. Only the first and second level functions are shown, and though several state 
functions such as “to be affordable,” “to be flexible” or “to be supportable” were 
significant concerns during design, they are not characterized as functions that the PADS 
would perform. 


Tabled. Description of Functions 


Number 

Function 

Description 

1 

Transit 

Transit from launch location to CARP 

1.1 

Attach 

Secure to launch platform (significant for externally mounted 
PADSs on UAVs) 

1.2 

Contain Parachute 

Contain parachute from launch to CARP (significant for externally 
mounted PADSs) 

2 

Separate 

Safe separation of PADS from launch platform which does not 
damage or place either component at risk 

2.1 

Release from Launeh 
Platform 

Release from launch platform with required arming and release 
functions performed 

2.2 

Deploy Paraehute 

Actuate release mechanism allowing parachute bag to open and 
parachute to deploy 

3 

Control 

Execute control of the PADS through steering line retraction 

3.1 

Sense Motion 

Measure and record current PADS attitude and acceleration 

3.2 

Aetuate Steering Lines 

Release and retract opposing steering lines during flight 

3.3 

Dampen Oseillation 

Control and reduce PADS roll, pitch, yaw oscillations 

3.4 

Respond to Operator 
Command 

Respond to operator input during PADS flight by non-specified 
means 

4 

Navigate 

Translate from PADS present position to desired IP 

4.1 

Determine Current 
Position 

Measure PADS current location and altitude 

4.2 

Estimate Winds 

Measure/calculate winds during descent profile 

4.3 

Maneuver to IP 

Based on present positon and predicted wind, adjust profile to 
desired IP 

5 

Communieate 

Communicate with operator 

5.1 

Reeeive Target 

Loeation 

Accept input of desired target location 

5.2 

Reeeive Navigation 
Information 

Accept input of present position and altitude 

5.3 

Transmit Wind 
Measurements 

Transmit calculated wind estimation for subsequent PADSs 

5.4 

Transmit Test Data 

Transmit compiled status and collected data for experimental 
analysis 

6 

Land 

Impact surface 

6.1 

Flare 

Maneuver control surfaces to reduce vertical speed on landing 

6.2 

Survive 

Withstand surface impact for subsequent use/experimentation 

6.3 

Preserve Test Data 

Preserve all flight test data for continues developmental testing 
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H. SUMMARY 


This chapter provided a summary of the technical activities included in the 
conceptual and preliminary design phases. It also defined the core problem that PADSs 
are designed to resolve and subsequently identified the basic functions that the system 
needs to execute in both an operational and experimental settings. The needs, wants and 
concerns of several stakeholders were detailed, as well as the design criteria that drove 
conceptual design. Points of contrast between operational and experimental system 
design criteria were highlighted. The chapter included several architecture decisions and 
described the influence of shifting design considerations on the architectural 
development. The operational concept for PADS employment was discussed and a 
functional analysis was specified. The application of the described systems engineering 
methodology to the development of the prototype Snowflake ADS is detailed in the 
following chapter. 
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IV. BLIZZARD SYSTEM COMPONENTS AND SNOWFLAKE 

ADS DESIGN 


In order to conduct initial and preliminary design experimentation, the updated 
Blizzard system consisted of the following four components: an Arcturus UAV, a 
modular AGU, a series of ram-air parachutes and the release/separation interface between 
the launch platform and the AGU. All of the components were required to perform the 
functions necessary to conduct a PADS experiment, and each is described in detail in this 
chapter. As initial and preliminary design is a highly iterative process, several of the early 
and intermediate designs have been omitted, except as noted. The Snowflake ADS design 
incorporated a high degree of modularity and flexibility in order to facilitate controlled 
changes to each of the components to correct expected and unexpected failure modes. 
Additionally, a comparison of the flight control dynamics between a conventional fixed- 
wing platform and the flight control dynamics of a ram-air parachute are described 
because the limitations presented proved significant in the construction and 
implementation of a functional ADS. 

A. ARCTURUS T-20 AND JUMP 20 

The Snowflake ADS was designed to maximize compatibility with any available 
UAV launch platform that could both support testing and potentially serve as a 
component in an operational Blizzard AADS. Fortunately, two versions of UAVs were 
available and used to support flight-testing at McMillan Airfield, Camp Roberts, CA: the 
fixed-wing Arcturus T-20 and a more advanced VTOL version called the JUMP 20. 
Specifications for each of the UAVs are shown in Table 5. During testing, the author 
would generally receive two-to-three-week’s notice of which type of UAV would be 
available, requiring the Snowflake ADS to be designed to support compatibility with 
diverse launch platforms with minimal modification. 
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Table 5. Comparison of Arcturus UAV Specifications Adapted from 
Arcturus UAV (2015a and 2015b). 


Specification 

T-20 

JUMP 20 

Type 

Conventional using pneumatie 
eatapult launeher 

Vertieal Takeoff and Landing 
(VTOL) 

Airframe 

Airframe monoeoque eomposite 

Airframe monoeoque eomposite 

Wing Span 

17’ 6” 

18’ 6” 

Length 

9’ 5” 

9’ 5” 

Engine 

190ee 4 Stroke 

190ee 4 Stroke 

Fuel 

MOGAS 

MOGAS 

Typieal MTOW 

185 pounds 

210 pounds 

Typieal Max Speed 

75kts 

72kts 

Enduranee 

10-20 hours (payload dependent) 

9-16 hours (payload dependent) 

Payload Capaeity 

75 pounds 

60 pounds 

Main Payload Bay 

4,100 eubie inehes 

4,100 eubie inehes 

Rated Ceiling 

15000’ (proven to 25000’) MSE 

15000’MSL 

Guidanee 

Full autonomous operation, launeh to 
land 

Full autonomous operation, launeh to 
land 

Charaeteristies 

Flight and reeovery under austere 
eonditions 

Flight and reeovery under austere 
eonditions 


1. T-20 

The T-20 is a fixed-wing fully autonomous UAV which had previously conducted 
research support with the Blizzard AADS and is shown in Figure 14. The T-20 offers 
slightly greater range, altitude, endurance and payload capacity when compared to the 
JUMP 20. However, it requires a relatively large pneumatic catapult for launch as well as 
a prepared surface for landing. The T-20 supported Snowflake payload deployment from 
either wing as well as conducting multiple deployments during the same flight. The T-20 
could reach launch altitude within roughly five minutes and required only minutes to 
conduct post-flight maintenance inspections and subsequent pre-flight and startup 
procedures. As such, the T-20 could support close to two experimental flights per hour. 
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Figure 14. Arcturus Fixed-Wing Version (T-20). Source: Arcturus UAV 

(2015a). 


2. JUMP 20 

The JUMP 20, shown in Figure 15, is a more advanced version of the T-20 which 
is designed to conduct VTOL operations. The VTOL capability offers a significant 
enhancement for shipboard operations where launch and land spaces are limited. The 
JUMP 20 does have a slightly reduced range and shorter endurance when compared to a 
conventional fixed-wing UAV. As it did not require a pneumatic catapult, the JUMP 20 
had centerline fuselage mounting stations in addition to the under wing stations. 
Unfortunately, its payload capacity is slightly smaller than the T-20, which would 
decrease its operational utility slightly. Additionally, when conducting flight 
experimentation, the JUMP 20 required significantly longer to reach an operational 
altitude and the time between launches was roughly twice that of the T-20. The post¬ 
flight electric charging requirement reduced the availability of the JUMP 20 by roughly 
50% as compared to the T-20. 
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Figure 15. Arcturus VTOL Version (JUMP 20). Source: Arcturus UAV 

(2015b). 


3. Integration 

Despite efforts to construct a Snowflake ADS that required mi n im um integration 
with the launch platform, the author remained subject to some distinctive differences in 
operation between a catapult-launched fixed-wing UAV and a VTOL UAV. Launches fi'om 
a T-20 subjected the Snowflake to an acceleration of approximately 5 Gs. As such, the 
internal components needed to be tightly secured and the external parachute container needed 
to be sufficiently robust to prevent parachute release shortly following launch. In contrast, the 
VTOL JUMP 20 had a very smooth and controlled launch acceleration of approximately 1.2 
Gs, which did not stress the parachute container on takeoff 

Though the JUMP 20 did not subject the Snowflake to the stress of a catapult 
launch, there was a much smaller threshold for harmful interference between the UAV 
and the Snowflake ADS. During the takeoff, landing and transition to and from forward 
flight, the vortices generated by the four rotors created highly turbulent airflow around 
the wing and the Snowflake. As such, the mounting hardware, static lines and parachute 
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deployment lanyards all had to be short enough to prevent harmful interference with the 
rotors. The relatively tight tolerances for mounting hardware presented a small, but 
manageable integration challenge between the two systems, but these were necessary 
precautions to prevent an increased risk of a catastrophic failure. 

B. AUTOMATED GUIDANCE UNIT 

The Snowflake ADS was composed of three elements: an AGU, a parachute, and 
the release/parachute deployment mechanism. Various iterations of the AGU were 
constructed during development, with the preponderance of effort focused on two 
different flight controllers and a power distribution design that would facilitate 
development, testing and repeated experimentation. The following section details the 
specifics and implementation of each type of flight controller, as well as the final design 
for a power distribution bus. 

I. Prototype with Pixhawk Flight Controller 

The Pixhawk flight controller from 3D Robotics, as shown in Figure 16, was initially 
chosen as a low-cost automated guidance unit. The Pixhawk is a commercially available, 
customizable, navigation and control platform used widely through the hobby and 
commercial UAV industry. The Pixhawk offers a three-axis gyroscope, a three-axis 
accelerometer/magnetometer, an onboard barometer for detecting altitude changes as well as 
integration for an external GPS receiver. The author also utilized the Pixhawk’s radio control 
integration to assist in developmental testing and to conduct controlled flight experiments. 
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Figure 16. Pixhawk Flight Computer and Installation in Prototype Snowflake 

ADS 

In addition to the previously described features, the Pixhawk was designed to be 
configurable for a variety of UAV platforms, to include multiple types of copters, ranging 
from one to eight blades, land-based roving vehicles and conventional fixed-wing 
aircraft. Working in conjunction with Lieutenant Commander Matthew O’Brian, the 
author determined that the Pixhawk would be able to provide satisfactory guidance and 
control for the Snowflake ADS at a sufficiently low-cost that operational employment in 
a one-time-use scenario would prove feasible. 

The prototype AGU also included two Tumigy TGY-6114MD digital sail winch 
servos secured to a custom-built mounting board made of G-10 glass epoxy composite 
laminate. Early designs utilized commercially available polycarbonate sheets, but the 
polycarbonate was not sufficiently strong to support all components under stress or to 
absorb the landing shock associated with an ADS touchdown. The Pixhawk and the 
servos were powered using a 2200mAh 7.4V 2-cell lithium polymer battery, which would 
provide adequate power for a roughly 20-minute flight. The author opted not to use a 
larger battery, theorizing that weight conservation in design would provide additional 

flexibility throughout development and ballast could be added if required. Finally, the 
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design included a HobbyKing HKU5 5V/5A battery eliminator circuit (BEC) to isolate 
servo power from the Pixhawk guidance unit. 

Externally, the author intended to inherit the parachute bag from the previous 
Snowflake ADS, but initial flight-testing proved nearly catastrophic as detailed in 
Chapter V. Following the initial flight tests, the parachute bag was redesigned by a small 
team consisting of the author and Major Alan Stephens as an element of the 
SE3201/SE3202/SE3203 design project course. In addition to correcting a potentially 
hazardous failure mode, the updated design was created to support the flexibility design 
consideration. The updated parachute bags, shown in Figure 17, would accommodate 
diverse parachute sizes and shapes as well as multiple release methods. As a final design 
had not been determined yet, the parachute bags were primarily designed to support 
repeated flight experimentation. The author planned to create a more fit-for-purpose 
design as development converged on a preferred parachute size, type and release method. 
Unfortunately, the design did not converge on a single parachute design and release 
sequence until after the author’s final flight-testing opportunity at McMillan Airfield in 
February 2016. 



Figure 17. Snowflake ADS Parachute Bag 


2. X-Monkey Flight Controller 

Following some of the experiments detailed in Chapter V, the design of the AGU 
evolved to incorporate a new flight controller more suitable for guidance, control and 
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experimentation. The X-Monkey from Ryan Mechatronics is a similar autopilot as the 
previously described Pixhawk, with three-axis gyroscopes, three-axis accelerometers and 
magnetometers and an integrated GPS. The Pixhawk and X-Monkey are similar in terms 
of the function of the internal components, and the cost is roughly comparable. In 
selecting the Pixhawk, the author hoped to incorporate COTS technology with a 
minimum amount of modification to deliver the functions required of an AGU in a 
PADS. Unfortunately, the author struggled with the requirement to modify the Pixhawk 
with little to no technical support available. As such, the author converted to a design 
utilizing the X-Monkey. The X-Monkey offered less performance out of the box, but 
offered a much more open software development platform suitable for modification to 
autonomous parachute control. It also had a more proven history of success in supporting 
scientific experimentation. Most importantly, the manufacturer was extremely responsive 
to technical support requests and provided significant assistance in the adaptation of 
control and guidance algorithms. 

In addition to the X-Monkey autopilot, the final prototype incorporated a Digi 
Zigbee 802.15.4 Radio module, which could be paired with the X-Monkey graphical user 
interface (GUI) for command and data transmission. Lastly, the final prototype was 
updated to include a 20-amp BEC/voltage regulator from Castle Creations. The internal 
components of the final Snowflake prototype, including the installed X-Monkey, are 
shown in Figure 18. 
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Figure 18. X-Monkey Flight Computer and Installation in Final Prototype 

Snowflake ADS 
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3. Power Supply and Distribution 

The power supply and distribution sub-system for the Snowflake AGU consisted 
of relatively simple COTS components, but required some adjustment to eliminate the 
need for additional batteries isolating the autopilot. Since modularity and maintainability 
were principal design considerations, the author created and maintained a design that could 
provide the necessary power to each component, offer limited electrical isolation of the 
more sensitive components and still be simple enough that the wiring harnesses could be 
exchanged in the held with minimal down time. An operationally suitable Snowflake AGU 
would likely have a bit more fit-for-purpose design elements, but the schematic shown in 
Figure 19 supported Snowflake flight control as well as data collection. 

As a Snowflake ADS flight experiment was roughly 20 minutes from power-up to 
landing, the relatively small 7.4-volt battery provided sufficient power to the control line 
servos, but a 20-amp capacity BEC was required to prevent the output from dropping 
below the five volts necessary to power the X-Monkey and to continue data recording. 
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Initial designs with a smaller capacity BEC occasionally caused the input power to the X- 
Monkey to drop below five volts and subsequently would trigger a reset. This reset would 
cause the X-Monkey to stop recording flight data for approximately five seconds and 
would reset the servo output commands to a neutral condition. The transient current 
spikes were caused by rapid reversals to the control lines or stalled conditions during 
parachute opening malfunctions. 



Figure 19. Electrical Power Distribution for Snowflake ADS 


C. RAM-AIR PARACHUTE SPECIFICATIONS 

Early design objectives were to incorporate a variety of available ram-air 
parachutes in order to evaluate which offered the best maneuverability and consistency. 
Unfortunately, several of the ram-air parachutes did not perform with sufficient reliability 
to asses and improve the design. As such, the implementation of each parachute is 
described below, with the final design converging on the rectangular ram-air parachute 
due to its relatively high build quality and consistent flight performance. 

1. Elliptical Ram-Air Parachute 

Initial designs for the updated Snowflake ADS were developed to utilize a 
commercially available elliptical ram-air parachute as shown in Figure 20. The elliptical 
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parachutes were a relatively low-cost design and offered the potential for enhanced 
maneuverability over the rectangular parachutes previously used in Snowflake ADS 
development. Preliminary experimentation indicated that parachute was approximately 
10 ft^, though exact measurements were not determined. The NPS ADSC Laboratory had 
a good supply of these elliptical parachutes, and they were initially thought to be suitable 
for repeated experimentation. Initial testing of the elliptical parachute conducted at NPS 
on May 1, 2015, as shown in Figure 20 demonstrated positive results, but it is significant 
to note that the tests were conducted with a nearly inflated parachute at release and the 
parachute bag had not been implemented yet. 



Figure 20. Elliptical Ram-Air Parachute Preliminary Testing on May 1, 2015 

2. Rectangular Ram-Air Parachutes 

Rectangular ram-air parachutes were also utilized in the design and 
experimentation process and proved to be significantly more reliable during flight 
experimentation, though they offered slightly reduced maneuverability. Experiments 
were conducted utilizing rectangular ram-air parachutes of two different sizes, as the 
Snowflake ADS was designed to work with a series of weight payloads. The 

specifications for the rectangular ram-air parachutes used are show in Figures 21 and 22. 
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In addition to their increased reliability, the rectangular parachutes were easier to pack 
and their construction was of a much higher quality than the elliptical parachutes had. 
Numerous unsuccessful attempts were made during the research process to procure 
additional parachutes of differing sizes and shapes to support testing. Parachute 
manufacture can be extremely expensive and the normally high cost was compounded by 
the fact that there is presently very limited co mm ercial utility for ram-air parachutes of 
this size. 

Though these parachutes offered relatively consistent performance during testing, 
there is some stretching noted in the lengths of the control lines that can potentially affect 
controllability. Early testing of the prototype Snowflake ADS included some relatively high 
velocity openings that yielded a substantial opening shock, likely stretching the control and 
support lines beyond their elastic limits. Later prototypes had a reduced opening shock, but 
the author was not able to repair the support and control lines without risking damage to the 
only viable flight-testing platforms. Replacements were not available. 




Rectangular Ram-Air Parachute 
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Figure 22. Overhead, Side and Control Line Specifications for 1.5 

Rectangular Ram-Air Parachute 


D. PARACHUTE DEPLOYMENT METHODS 

When the Snowflake ADS was functionally decomposed in Chapter III, one of the 
first level function is “F2.0 To Separate.” In conceptual design, the author assumed this 
would be a relatively simple function to complete and it could be accomplished with 
minimal complexity. Through the conceptual and preliminary design, three types of 
separation mechanisms were utilized, starting with a servo-actuated release, progressing 
to a static line release pin and finally to a double static line release. 

1. Servo-Actuated Release 

The initial prototype adapted the previously used design that incorporated a servo- 
release pin, that could be operator actuated by radio control or sensor actuated by the 
autopilot based on a combination of programmed conditions. This design sequence is 
shown graphically in Figure 23. A servo-actuated release was preferred initially because 
it would offer the capability for the Snowflake ADS to separate from the launch platform, 
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fall ballistically for a period of time and then open the parachute bag at an optimum 
altitude or location to minimize displacement error on landing. The author theorized that 
the Snowflake ADS could support release from medium altitude, reduce exposure time 
by falling ballistically and then deploy the parachute at the optimum moment. 
Additionally, this design required very limited integration with the launch platform. The 
Snowflake ADS could be mounted within seconds, and no additional attachments were 
required that would increase the complexity of the design. Though these were useful 
design features for an operationally suitable system, they were not required to support 
early testing. 





Remote servo 
actuation opens 
bag and parachute 
released 

Parachute bag 
secured with servo 
actuated pin 

Snowflake released 




Figure 23. Servo-Actuated Release Sequence 


Unfortunately, on the first two test flights, there was a pre-deployment of the 

parachute immediately after the JUMP 20 executed its transition from vertical to forward 

flight. Subsequent post-flight failure analysis determined there were two potential failures 

contributing to the pre-deployment: failure of the parachute bag to contain the parachute 

or premature actuation of the release pin due to an unknown condition. As the root cause 

could not be specifically determined and corrected, the design team implemented two 

changes to eliminate the potential of a reoccurrence: the parachute bag was 

fundamentally redesigned, and the servo-actuated release was removed until the possible 

transient behavior of the autopilot could be understood better. 
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Static Release Pin 


Following the initial prototype, the static release pin sequence shown in Figure 24 
was implemented. The parachute bag was kept closed by a cotter pin secured to the 
mounting block on the launch platform as shown in Figure 25. This design had a slightly 
higher integration requirement. The Snowflake had to be mounted under the wing with a 
static line attached for each flight. As the static line remained underneath the launch 
platform for the duration of the flight, the author had to consider any potentially harmful 
effects. Specifically, on the JUMP 20, the static line was approximately 12 inches from 
the spinning blade of the aft lift fan. There was no clearance issue during launch or 
forward flight; however, the design could not interfere with a high velocity propeller 
providing thrust during landing. With this consideration in mind, the static line had to be 
sufficiently long to release the cotter pin on the parachute bag, but only had about one 
inch before potentially impacting the lift fan. This requirement added roughly five 
minutes to the Snowflake ADS loading sequence as the static line had to be measured and 
confirmed separately for each Snowflake ADS. 



released 


Figure 24. Static Release Pin Sequence 

This design served to be robust and consistent, but following a series of failures in 
which the parachute did not deploy from the parachute bag, the design was adjusted to 
incorporate a second static line tether to assist in deploying the parachute immediately 
following release. 
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Figure 25. Installed Static Release Pin 


3. Tethered Deployment 

The double static line sequence, shown in Figures 26 and 27, was implemented on 
the final Snowflake ADS prototype to address repeated failures cleanly releasing and 
deploying a parachute. This design removed the capability of a servo-actuated release and 
could potentially limit the operational utility of the system. The author applied a systems 
engineering design methodology by characterizing the servo-actuated release as a 
desirable additional capability but not worth the associated complexity cost. In order to 
design a prototype that could support flight experimentation and data collection, the 
author adapted a double static line sequence that proved highly reliable and consistent for 
low altitude ADS flight profiles. 

Given that the double static line method was still required to work on both types 
of UAVs, the requirement to minimize or eliminate destructive flight interference was 
present and included. Each parachute was fitted with an approximately six-foot lanyard to 
the middle of the upper surface of the ram-air parachute. The lanyard was connected to a 
12-inch static line that remained secured to the mounting block on the launch platform. 
The lanyards were connected by two small rubber bands designed to break at 
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approximately six pounds of force, roughly equivalent to the weight of a Snowflake 
ADS. The six-foot lanyard was packed inside the parachute bag and would extend as the 
Snowflake was released and the parachute bag was opened. This second tether would 
provide a small but sufficient force to pull the parachute into the airstream and initiate 
inflation. As the inflation was initiated so quickly, the opening shock was minimized as 
well as the chaotic three-axis rotation that accompanied the release. The greatly reduced 
release dynamics contributed significantly to consistent parachute inflation suitable for 
control and precise navigation. 




Figure 26. Double Static Line Deployment Sequence 
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Cotter pin release line 
is on front of Snowflake ADS 
(not shown) 


12 Static lanyard 
(stayed with launch platform) 


Elastic breakaway 


6’ Lanyard 

(secured to top of parachute) 


Figure 27. Installed Double Static Line 


E. FLIGHT CONTROL DYNAMICS 

The following section details some of the differences between the flight control 
dynamics of a fixed-wing aircraft and the flight control dynamics of a ram-air parachute. 
As most COTS flight controllers are designed to work with fixed or rotary-wing aircraft, 
it is essential to detail the subtle differences which preclude flight control of ram-air 
parachute with a fixed-wing dynamics without significant modification. 

1. Fixed-Wing Aircraft 

In addition to the results described in Chapter V, a comparison of the difference 
between the flight control dynamics of a fixed-wing aircraft and a ram-air parachute was 
essential in the selection of an appropriate flight controller. When considering that a 
principal design consideration was the use of COTS components because of their low 
initial cost, the author selected the Pixhawk autopilot as being one of the more developed 
units within the commercial autopilot industry. It offered a great deal of customizability 
for use in roving land vehicles, fixed-wing aircraft and multiple versions of copters. The 
author expected to adapt a fixed-wing profile for use in the Snowflake ADS as it was the 
most closely related. 
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The control inputs and associated platform responses of a fixed-wing aircraft are 
shown in Figure 28. Each control surface (ailerons, elevators or rudders) offers both a 
positive and negative control deflection to produce a platform response (roll, pitch or 
yaw). Though modem flight control systems often optimize and integrate these control 
surface deflections, the initial Snowflake design was to decouple them to develop a single 
input single output (SISO) model of the flight dynamics of each platform axis. The 
Pixhawk flight controller offered the ability to match the control surfaces shown, with 
some degree of customization to account for control surface travel limitations. 
Additionally, it did offer modes that utilized elevens to control concurrently both the roll 
and the pitch. Through experimentation, it proved extremely difficult to disable or 
minimize the aileron/elevon roll commands. 


Control Surface Platform 

Deflection Response 


Perpendicular Axis: Yaw 
Using Rudder 




Right Aileron Travel: 
(Side View) 



Left Aileron Travel: 
(Side View) 



Elevator Travel: 
(Side View) 



♦ . Negative Roll 

(Positive) 


Down 
(Negative) 

/V Up 

(Negative) 


Positive Roll 
Positive Roll 


Down 
(Positive) 

/V Up 

(Negative) 


Negative Roll 
Positive Pitch 


Down 

(Positive) 


Negative Pitch 


/V 


Right 

(Negative) 


Positive Yaw 


Rudder Travel ^ 

(Top View) 


Left 
(Positive) 


Negative Yaw 


Figure 28. Description of Flight Control Inputs and Response of Fixed-Wing 

Aircraft 


2. Ram-Air Parachute 

In contrast to the fixed-wing flight dynamics, the flight control input to platform 
response of the ram-air parachute is shown in Figure 29. It is significant to highlight that 
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though controlling the pitch and roll of a guided ram-air parachute is still possible, the 
principal concern for initial design was maneuver about the perpendicular axis through 
yaw control in order to execute autonomous navigation. Unfortunately, the ram-air 
parachute does not offer a bi-directional platform response associated with bi-directional 
control surface deflection. Since the control lines can only be retracted, there is no way to 
cause a negative control surface deflection on the parachute. Consequently, the two 
control lines had to oppose each other, with each providing independent positive control 
deflection only. 



Platform 

Response 

None 


Positive Yaw 


None 


Negative Yaw 


Perpendicular Axis: 

Yaw Using Trailing Edge Flap 

Figure 29. Description of Flight Control Inputs and Response of Ram-Air 

Parachute 


The Snowflake ADS could also be expected to require pitch control in an effort to 
execute a terminal maneuver to minimize descent rate just prior to touchdown. This 
platform pitch could be accomplished with a concurrent positive control surface 
deflection. In contrast to the yaw control, which required opposing control surface 
deflections, a positive platform pitch can only be implemented by using paired positive 
control surface inputs. 
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3. Challenges during AGU Development 

The differences between control of a fixed-wing platform and a ram-air parachute 
proved to be much more significant than anticipated. Moreover, the operating platform of 
the Pixhawk did not facilitate easy creation of a fully customized flight program. 
Unfortunately, there was minimal customer support provided to facilitate this 
customization. The Pixhawk did not offer the ability to offer opposing control line 
retractions to control yaw, the ability to decouple roll control inputs to produce a yaw 
response and the ability to provide synchronous dual control line pitch control. 

As a result of these limitations, the author, in conjunction with Lieutenant 
Commander O’Brian, opted to switch to the X-Monkey flight controller due to its greater 
customizability and the availability of customer support. 

F. SUMMARY 

In this chapter, the conceptual and preliminary design of a Snowflake ADS and 
several additional components of the Blizzard AADS are described. The specifications 
for the two types of UAVs that were utilized in flight-testing are included. Subsequently, 
several iterations and a final prototype design are summarized, including the installation 
and usage of two types of autopilot computers. A description of the final design for 
power distribution is detailed, as early iterations contributed to unexpected failures in 
testing and experimentation. This chapter also includes a description of each type of ram 
air parachute that was tested, as well as the three types of UAV/Snowflake separation 
sequences. A comparison of the principles of flight control dynamics between fixed-wing 
platforms and a ram air parachute platform is incorporated, as it proved to be a significant 
challenge in the implementation of COTS technology. Comprehensive computer 
simulation and flight-test results of the various prototypes are detailed in Chapter V. 
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V. COMPUTER SIMULATIONS AND FLIGHT-TEST RESULTS 


Between April 6, 2015, and February 18, 2016, 65 live flight experiments were 
conducted at McMillan Airfield, Camp Roberts, CA. Additionally, there was a series of 
lab experiments performed in the AD SC laboratory at NFS before and following the 
February 2016 flight tests. This chapter details the results of those flight experiments, as 
well as the associated laboratory experiments, in preparation for planned flight-testing in 
May 2016 in support of Lieutenant Commander O’Brian’s continuation of the research 
effort. 

A. FAILURE MODES 

This section includes separate failure analyses of the three types of parachute 
deployment methods, as well as compiled results on the success of both autopilot 
computers in performing the data recording function. Though a significant amount of 
effort was placed on prior lab testing, the uncertainty associated with live flight-testing 
continued to reveal unexpected weaknesses in the design. 

1. Parachute Deployment Methods 

The comprehensive results presented in Figure 30, show the various design 

iterations that the author incorporated during a nearly 10-month period. Following the 

nearly catastrophic results of April 6, 2015, the author converted from a servo-actuated 

release to a static release pin to simplify the design and prevent a potential reoccurrence 

of early canopy release. Once the risk of a catastrophic failure was reduced with the 

newly design parachute bag, the design emphasis shifted toward remedying a consistent 

problem of fouled or tangled parachute releases. All flight tests from April to June 2015 

included the use of the previously discussed elliptical parachute design, which continued 

to deploy in an unpredictable fashion, frequently including full riser twists, line-overs and 

partial deployments. Initially, the author theorized that variability in the parachute 

packing technique was to blame for the inconsistent results but subsequently determined 

that the low manufacturing quality of the elliptical parachutes was a more likely cause. 

Additionally, the elliptical parachutes used cascade lines that were mounted laterally 
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across multiple cells rather than along the seam of a single rib. With only one clean and 
controllable parachute release in the first 10 flight tests, the author transitioned to the 
rectangular parachutes described earlier for the August 2015 flight tests. 



Figure 30. Failure Analysis of Snowflake Parachute Deployment Methods 


The results of the August and September 2015 flight tests were successful in that 
they demonstrated a slight improvement in the likelihood of a clean parachute release 
when using the rectangular parafoil. Unfortunately, the flight tests revealed a previously 
unidentified problem with the parachute bag failing to open during ffeefall. As 
constructed, the design required sufficient drag to open the parachute bag and release the 
parachute. However, due to the design changes incorporated following the April 2015 
tests to reduce the risk of parachute pre-deployment during the flight to release altitude, 
the parachute bag was now unable to provide a consistent opening. The bag had been 
constructed to survive a roughly 10-minute flight to release altitude at airspeeds 
approaching 50 knots. Even when the static release pin was pulled during the release, 
there was an insufficient drag force to open the parachute bag. Frequently, the Snowflake 


58 





























would free-fall for close to 1500 feet before opening. When the parachute did release at 
these free-fall airspeeds, the associated opening shock caused significant stress on the 
internal components of the Snowflake as well as on the connecting hardware. During the 
August and September 2015 flight-testing, the parachute bag failed to open three times, 
each resulting in a ballistic profile terminating in complete disintegration on impact. The 
images shown in Figure 31 reveal some of the parachute malfunctions that plagued the 
single static release pin implementation. Of the 32 flight tests conducted with the static 
release pin design, only seven yielded a parachute that was fully inflated and controllable. 



Rectangular 
Parachute: Fouled 
Release 


Elliptical 
Parachute: Full 
Riser Twist 


Rectangular 
Parachute: Full 
Riser Twist 


Rectangular 
Parachute: Partial 
Inflation 


Figure 31. Representative Parachute Malfunctions Using Single Static Line 

Release Pin 


As a result of the previously described inability to separate from the launch 

platform and deploy a parachute in a manner supporting control, the double static line 

deployment sequence was implemented during field testing in September 2015. The 
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sequence did have a few variations in development, but converged on the design 
discussed in Chapter IV. Results for the double static line deployment sequence 
demonstrated consistent performance by yielding a parachute deemed suitable for control 
in 29 of 31 flight experiments. Additionally, the two failures of the double static line 
sequence were fouled releases not representing the hazardous conditions produced by 
previous designs. 



Figure 32. Representative Successful Parachute Inflations Using Double 

Static Line Deployment Sequence 


2. Support for Experimental Data Collection 

Given that the parachute sequence had begun to demonstrate relatively consistent 
and successful results, the author’s design emphasis began to shift to analysis of the data 
being collected by the Pixhawk autopilot in September and December 2015. As shown in 
Table 6 and Figure 33, the Pixhawk autopilot proved unreliable in sensing, preserving 
and recording the experimental flight data required for control and navigation. Though 
various lab and flight experiments were attempted, the author was never able to isolate 
the fundamental causes of the failure to capture flight data. The author determined that 
the complex series of sensors required to conduct a flight experiment needed to be 
powered and functioning appropriately for the autopilot to remain armed and recording 
data. The most likely cause was repeated high magnitude deceleration, experienced on 
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either ground impact or in high velocity parachute deployment. Any transient interruption 
in the power supply or telemetry link could cause the Pixhawk to change flight modes 
and negatively impact its ability to record and preserve data. 


Table 6. Summary of Autopilot Data Collection Results 


Autopilot 

No Data Recorded 

Data Invalid 

Data Valid 

Total 

Number 
of Flights 

%of 

Total 

Number 
of Flights 

% of 
Total 

Number of 
Flights 

%of 

Total 

Pixhawk 

24 

45.3% 

10 

18.9% 

19 

35.8% 
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X-Monkey 

0 

0.0% 

0 

0.0% 

12 

100.0% 

12 

Totals 

24 

36.9% 

10 

15.4% 

31 

47.7% 
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Figure 33. Summary of Autopilot Data Collection Results 


In addition to the failure to record useful data, the Pixhawk was also subject to 

multiple small sensor component failures that would cause gross errors in the information 

being recorded. These failures were often undetectable during pre-flight programming 

They would only manifest themselves on subsequent data analysis revealing inaccurate 
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magnetic heading, altitude or GPS position information. As a result of this inability to 
adequately record experimental data, the author determined it was not suitable for use in 
the Snowflake platform and replaced it with the previously described X-Monkey which 
demonstrated significant improvement in reliability and consistency. In contrast to the 
Pixhawk recording valid data on 35.8% of its test flights, the X-Monkey has 
demonstrated 100% success in collecting and preserving flight data through 12 flight 
experiments. 

B. COORDINATE TRANSFORMATION AND FLIGHT PROFILES 

This section details the homogeneous coordinate transformation used to convert 
the X-Monkey autopilot flight data to a more usable reference frame, including a 
description on the use of quaternions. Additionally, this section includes samples of 
sensor data from lab experiments as well as representative flight data from a controlled 
Snowflake flight experiment. 

I. Coordinate Transformation 

Positioning the X-Monkey inside the Snowflake required performing a coordinate 
transformation to convert effectively the recorded sensor data, which was expressed in 
the sensor frame { 5 }, to the body coordinate frame {b} for the Snowflake. The rotation 
matrix {R) shown below represents the orientation rotation of the X-Monkey sensor to the 
Snowflake body frame in terms of the Euler angles ((p,d,y/) required to rotate the 
coordinate frame. The Euler angles for the X-Monkey to Snowflake rotation matrix are 
shown in Figure 34. 
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Figure 34. Coordinate Frame Relationship Between X-Monkey Sensor Frame 

and Snowflake Body Frame 
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The rotation matrix {R) was also converted to a quaternion vector (Q) to aid in 
post-flight processing as well as to facilitate implementation into the X-Monkey 
operating software, which internally utilized quaternions. Though the data outputted by 
the X-Monkey is in its native sensor frame, there is a series of internal routines that 
incorporate and utilize quaternion rotation sequences. The author expects that Lieutenant 


63 


















^12-^21 0-(l) Q5 

Aq, 4(0.5) 

0.5 
0.5 
0.5 
-0.5 

Similarly, the same coordinate transformation was applied to the X-Monkey Euler 
angle rates {(p), (9) and (ip) to transform the values to Snowflake Euler angle rates in 
post-flight processing. 



2. Lab Testing 

To confirm the correct operation of the quaternion operator identified earlier, the 
author conducted a series of laboratory experiments. In each experiment, an X-Monkey 
was installed as shown in Figure 34 and multiple scripted experiments were conducted. 
Primarily, the Snowflake was rotated 360 degrees of positive pitch, 360 degrees of 
positive roll and 360 degrees of positive yaw. The experiment took approximately 30 
seconds to complete and included downloading the experimental data file from the X- 
Monkey and importing into MATLAB for processing using one of the scripts shown in 
the Appendix. Representative results from an experiment are shown in Figures 35 and 36. 

The Euler angle data were adjusted in MATLAB to convert the output angles 
from the X-Monkey to a more useful range. The range of roll angles was converted to +/- 
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180 degrees, the pitch angles were converted to +/- 90 degrees and the yaw angles were 
converted to a range from 0-360 degrees using the wrapToiso function in MATLAB. 
The roll and yaw transients exhibited in Figure 35, which occurred during the 360-degree 
positive pitch rotation, were expected variations associated with a 90 degree pitch 
up/pitch down orientation. 


Snowflake Euler Angles 



360 degree 
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Figure 35. Lab Experiment Results: Snowflake Euler Angles following 

Coordinate Transformation 

Additionally, the Euler angle rates recorded during this experiment were also 
shifted from the X-Monkey orientation to the more appropriate Snowflake orientation as 
shown in Figure 36. The raw sensor output data were filtered using a one dimensional 
median filter function (raedfiiti) in MATLAB to reduce some of the high frequency 
noise in the rate sensors and to make the experimental output a bit more intuitive. 
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Figure 36. Lab Experiment Results: Snowflake Euler Angle Rates following 

Coordinate Transformation 


3. Flight Tests 

From February 18-19, 2016, 12 live flight experiments were conducted at 
McMillan Airfield, Camp Roberts, CA utilizing the Snowflake ADS with an installed X- 
Monkey. Each of these flights utilized the double static line release sequence, with 11 of 
12 flights resulting in a full canopy inflation. The one failure was attributed to a snag in 
the parachute support lines when utilizing a spreader, which was subsequently removed. 
Comprehensive post-flight data analysis was conducted to gain insight into the dynamics 
associated with launch, separation from releasing aircraft and steady state autonomous 
flight. In each of these experiments, the control line retraction was systematically varied 
to induce a heading change in the platform. This data was to be utilized to construct a 
SISO model of the Snowflake for subsequent control system design. The principal 
objectives of these tests were to validate the airframe separation mechanism and to 
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collect meaningful data on the flight profile. Both of which were achieved. The data 
shown in Figures 37 through 42, are from a single flight which was representative of each 
of the 12 flight experiments. In this particular example, the Snowflake was programmed 
with a two-centimeter retraction of the right control line to induce a positive yaw. 

A bird’s-eye view of the GPS position of the Snowflake is shown in Figure 37 
shortly after release from the launch aircraft at an altitude of approximately 2,000 above 
ground level (AGL). As the double static line sequence was utilized, the Snowflake 
release and parachute deployment occurred nearly simultaneously. The author defined a 
steady state period of autonomous Snowflake flight beginning five seconds after 
parachute deployment to five seconds before touchdown. This helped in isolating the 
dynamics and oscillations associated with parachute release. The flight control program is 
designed to actuate following this transient condition and provide guidance to the pre¬ 
programmed destination. The isolation of the five seconds prior to touchdown was done 
to facilitate scaling during data analysis as the transients on landing tended to mask the 
steady state flight characteristics. 
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Camp Roberts Bird's-Eye View 
McMiiian Airfieid, Camp Roberts, CA 



Figure 37. Flight Test Results: Bird’s-Eye View 

The same flight experiment is represented three-dimensionally in Figure 38. The 
canopy deployment, steady state definitions and touchdown points are all shown. 
Additionally, the flight profile is displayed using sensor input from the X-Monkey 
barometric altimeter as well as the altitude reported from the internal GPS. In this 
example, there is a distinct difference between the two, but a comprehensive analysis of 
all test results demonstrated significant unreliability in the accuracy of the GPS position 
and altitude. Until the source of the GPS instability can be isolated, usage of the 
barometric altimeter is recommended. Additionally, analysis of the discrepancy between 
the two altitude sensors will be required to determine precise estimate of the above 
ground level (AGE) altitude in order to refine terminal control and accuracy. 
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Camp Roberts 3 Dimensional View 
McMillan Airfield, Camp Roberts, CA 
18-Feb-2016 21:03:00 
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Figure 38. Flight Test Results: Three-Dimensional View 


More data from this flight experiment are shown in Figure 39, which shows a 
clear delineation of the three separate elements of the flight, additional levels of detail in 
the GPS sensor as well as the magnitude of total acceleration recorded by the three-axis 
accelerometers within the X-Monkey. The top plot of the altitude profile is combined 
with the second plot of total acceleration to define significant flight events for data 
analysis. The acceleration spikes at approximately 350 seconds, 630 seconds and 750 
seconds, represent the catapult launch of the UAV, the release of the Snowflake ADS and 
the impact with the ground. Various other conditions were investigated, but the total 
acceleration was deemed most reliable in isolating these significant flight events. 
Additionally, in the top plot of Figure 39, the erroneous altitude reported by the GPS 
sensor is shown. 
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Full Altitude Profile 
McMillan Airfield, Camp Roberts, CA 
18-Feb-2016 21:03:00 
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Figure 39. Flight Test Results: Altitude Profile, Total Acceleration and GPS 

Ground Speed/Track 


The Snowflake autonomous flight segment is expanded in Figure 40 to reveal the 
individual components of the velocity as reported by the GPS in the X-Monkey. The 
north and east components (Vn and Ve) are shown in the top plot, the down component 
(Vd) in the second plot and the composite ground track velocity component (Vg) in the 
bottom plot. The ground velocity was calculated in post-flight processing using the 
following expression: 

The mean values for the down and ground component velocities, (Vd) and (Vg), 
respectively, were calculated and are shown in Figure 40 as well. The ground velocity 
value (Vg) is useful for completing real time wind estimation, though the X-Monkey will 

70 




































need an installed onboard airspeed sensor in subsequent design iterations if this 
functionality is to be implemented successfully. Providing there is little or negligible 
vertical wind component, the GPS vertical velocity component (Fd) is sufficiently 
accurate to facilitate flight path prediction and glideslope management in the terminal 
phase. 

GPS Velocity Data 

McMillan Airfield, Camp Roberts, CA 
18-Feb-2016 21:03:00 

4 

^ 2 

CO 

1 0 

m -2 
z 

> -4 
-6 

640 650 660 670 680 690 700 710 720 730 740 





Figure 40. Flight Test Results: Snowflake Autonomous Flight GPS Velocity 

Components 

The Euler orientation of the Snowflake during this autonomous flight segment is 
shown in Figure 41. Unfortunately, the data shown highlight a problem with the magnetic 
calibration of the X-Monkey that manifested itself in flight-testing. The hardware version 
of the X-Monkey had an internal software error that has since been corrected. The magnetic 
calibration reference vector was not being saved correctly, which produced the erroneous 
yaw angles represented in the data. From the flight path reconstruction data presented 
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earlier in Figures 37 and 38, the Snowflake executed two right 360-degree rotations about 
the yaw axis, but the recorded Euler headings are within a range of 75 to 150 degrees. 


Snowflake Euler Angles 
McMillan Airfield, Camp Roberts, CA 
18-Feb-2016 21:03:00 





Figure 41. Flight Test Results: Snowflake Euler Angles 


Figure 42 shows an expanded comparison of the Euler yaw heading and the GPS 
ground track during the period of autonomous Snowflake flight. Again, the erroneous 
heading information is shown, but this comparison is expected to be useful for 
conducting a real-time wind estimation. The magnetic reference vector calibration error 
has subsequently been corrected, and the correct Euler orientations have been verified 
correct in a series of lab experiments conducted in the ADSC lab. 
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Yaw Angle vs GPS Ground Track 
McMillan Airfield, Camp Roberts, CA 
18-Feb-2016 21:03:00 



Figure 42. Flight Test Results: Snowflake Yaw Angle versus GPS Ground 

Track 

Finally, a representative flight sequence of the Snowflake ADS is shown in Figure 
43. This sequence is a compilation of several flights showing the diverse nature of the 
experiments. The Snowflake ADS was successfully employed from two different types of 
UAVs, utilized three uniquely developed separation sequences, incorporated two 
different autopilot computers and collected experimental data from autonomous as well 
as radio controlled back-up modes. The data collected and the methods for analysis are 
presented to assist future research endeavors in refining the control and guidance 
algorithms to enhance terminal accuracy. 
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Static Line Release (JUMP-20) 




Catapult Launch (T-20) 


Radio Controlled Flight 


Autonomous Flight 


Figure 43. Compiled Snowflake ADS Test Sequence 


C. SUMMARY 

This chapter compiled the 65 flight tests conducted over a nearly ten-month 
period, as well as several simulations conducted in the ADSC laboratory at NFS. The 
results from the flight tests are correlated with sequential improvements in the parachute 
deployment methods that were derived from failure mode analysis. Additionally, the 
ability of each autopilot to capture and retain valid experimental data is described, as it 
directly influenced the author’s conversion from the Pixhawk to the X-Monkey flight 
computer. Once successful flight data was recorded, this chapter detailed various lab 
simulations and the mathematics used to convert recorded data to a more useful 
coordinate frame using quaternions. Subsequently, a representative flight profile is 
described and illustrated to facilitate follow-on control system development. The results 
from these flight and computer simulations are used to derive several conclusions relating 
to the viability of COTS technology to produce low-cost micro-light weight PADSs that 
can provide additional capability to the battlefield. 
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VI. CONCLUSION AND RECOMMENDATIONS 


A. CONCLUSION 

Based on theoretical analysis and assessment of the flight-test results, the author’s 
overall conclusion is that low-cost, COTS navigation components are likely to provide 
sufficient accuracy and reliability to close the capability gap between the PADSs 
currently in operation and the combat operational need for rapid-response, tactical 
logistical resupply in austere and dispersed locations. More research is needed to provide 
conclusive evidence as to the economic viability of a highly accurate, purpose built 
micro-light weight class PADSs when contrasted with potential multiple use alternatives. 

In addition to the above conclusion, several additional conclusions are offered to 
address the secondary research objectives. Operational limitations for employment are 
discussed as well as several conclusions derived from the application of systems 
engineering methodologies to the construction of several initial prototypes and the 
completion of a technical research effort at NPS. 

1. Operational Employment Limitations of Micro-Light Weight PADSs 

The accuracy of the Snowflake ADS is still being developed and enhanced, 
however this research effort has realized some potential shortcomings associated with 
operational employment. Micro-light weight PADSs have an inherent requirement to be 
small and inexpensive to alleviate the warfighter from being required to retain and return 
the PADS for reuse. If the cost or complexity associated with a micro-light weight PADS 
grows to the point where it can no longer be considered disposable, then it becomes 
questionable as to whether a PADS is the preferred method for logistical delivery. Only 
in the specific case when long-range resupply is required, is a PADS able to outperform a 
small package delivered via more conventional vertical takeoff and landing UAS, such as 
a quad copter. 

As this research uncovered, the cost to commercially procure a single rectangular 

ram-air parachute is approximately $400. Viable economy of scale production will most 

assuredly reduce the cost to construct a ram-air parachute with sufficient build quality to 
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support failure rate reduction. Though this research did not include a full cost analysis to 
procure a developed system, cost efficiency must be balanced with the requirement for 
increased terminal accuracy. As the burdening of a tactically engaged warfighter with the 
responsibility to return a purpose-built ram-air parachute is undesirable, continued 
improvements in micro-light PADSs must be implemented in a manner which retains the 
attribute of being a single-use item. 

This conclusion was reached as a result of the application of the systems 
engineering methodology to research and understand the core user/stakeholder needs and 
resultant requirements. The need demonstrated by the hypothetical user in most 
CONOPS, is for logistical resupply, not for logistical resupply via PADS. As such, the 
systems engineering methodology was an effective tool in the development of the 
Snowflake ADS in that it had to be the best approach to meeting the core stakeholder 
needs. 


2. Application of Systems Engineering Methodology 

Traditional and Agile methodologies were critical tools in the conceptual and 
preliminary design of a micro-light weight class PADS. The ability to rapidly respond to 
failures, identify root causes and incorporate multiple design changes though iteration 
was critical in development. Additionally, the ability to identify emerging 
user/stakeholder needs and rapidly iterate accordingly was instrumental to the success 
that was achieved. Lastly, the application of various design thinking principles to identify 
solutions based on desired functionality enhanced development when contrasted to 
component specific solutions. 

3. Prototype Design for Operational as Compared to Developmental 
Objectives 

Though the systems engineering principles identified earlier were instrumental in 
design, there were some identified shortfalls in a design focused purely on the end users 
specified needs. Analysis of stakeholder needs was crucial and valuable, but it did not 
necessarily produce an effective “Big Design Up Fronf’ in the conceptual and 
preliminary design phases. The number of design iterations required simply to support 
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developmental testing was significant. As such, it was necessary to identify additional 
effective needs for various phases of development in order to successfully design a 
prototype suitable for operational employment. 

4. Integration of Multi-Domain NPS Engineering Curriculum 

The most rewarding aspect of this research endeavor has been the ability to 
engage with engineering faculty and students outside of the Systems Engineering 
Department at NPS. The author believes that the quantity and quality of learning was 
magnified significantly through the application of the systems engineering methodology 
to an ongoing engineering project, commencing with initial design and culminating with 
field experimentation. This research has allowed the author to investigate robotic 
fundamentals, unmanned systems navigation systems and classic control while designing 
and integrating a complete PADS. 

In contrast, the author strongly believes that the application of systems 
engineering toward an abstract or theoretical problem is counterproductive. Systems 
engineering education must include the application of concepts toward a complex applied 
engineering effort. Failure to do so is a disservice to the both the system engineer and the 
teams of domain specific engineers. The author frequently observed how a domain 
specific engineer could focus on a specific solution and lose sight of the broader 
functionality that was trying to be achieved. The systems engineering methodology was 
useful in this regard. In contrast, an abstract systems engineer who lacks a basic 
understanding of the underlying engineering complexity associated with design and 
testing lends little to the project. 

5. Continuity and Documentation of Research Effort 

The author began this research endeavor with the intention of improving the 

results of previous students. Unfortunately, the lack of continuity in the project 

contributed greatly to the overall complexity and difficulty. The author spent close to 

nine months getting the research platform back to the level of capability where it was a 

few years ago. As software and hardware are revised continually, the period of viability 

associated with the equipment in any research project is much shorter than expected. For 
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the Snowflake ADS, or any research project to continue to evolve and improve, there 
must be a continuous supply of students or laboratory technicians who are familiar with 
the technical specifications of the project. 

B. RECOMMENDATIONS FOR TECHNICAL IMPROVEMENTS 

The recommendations provided are a small sample of the technical areas in which 
the Snowflake ADS prototype could be improved to enhance its navigational accuracy 
and associated operational utility. As the final prototype is suitable for subsequent 
scientific experimentation, significant room for improvement exists before the utility of a 
micro-light weight class PADS can be fully explored in an operational setting. 

1. Guidance and Control Algorithms 

The parallel effort of Lieutenant Commander O’Brian to implement a guidance 
and control algorithm into the X-Monkey autopilot is a significant undertaking, but 
necessary for the development of autonomous navigation. Due to the earlier described 
failures in the preliminary design, the author was not able to collect comprehensive data 
to assist in developing a SISO model linking control line retraction to Snowflake yaw 
angle. The late transition from the Pixhawk autopilot to the X-Monkey autopilot 
contributed to the latency in developing a control algorithm as the two autopilots are 
programmed completely differently. 

In addition to the SISO control line retraction to yaw rate model, a multiple input 
multiple output (MIMO) model can be created to simultaneously control the yaw, provide 
some measure of roll damping during the descent as well as offer pitch response to 
accommodate changes in forward velocity. The dual input associated with independent 
actuation of the left and right control lines can be used to examine a variety of outputs 
through the use of state space design techniques. 

2. Robustness of GPS Navigation Solution 

Experiments conducted using the X-Monkey demonstrated some small reliability 
inconsistencies with the GPS sensor data. Due to the relatively low power of a received 
GPS signal and the internally mounted X-Money, future design iterations must include 
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the external GPS antenna to boost signal reception. If the external antenna does not 
provide the necessary additional signal strength, then a pre-flight verification of GPS 
signal strength is necessary prior to experimentation. As the X-Monkey can be expected 
to sustain a roughly 5 G impact on landing, the veracity of the navigation solution must 
be confirmed prior to follow-on experimentation. 

3. Wind Estimation 

To enhance the accuracy of the Snowflake ADS, the AGU must be able to 
measure and refine real-time wind speed and direction. The integration of an externally 
mounted airspeed sensor to the X-Monkey was considered, but not implemented in the 
course of this research due to insufficient time and available flight-testing. External 
airspeed sensors increase the risk for parachute tangles/malfunctions on deployment and 
are unlikely to have the precision required for low-airspeed flight and wind estimation 
with rapidly changing platform orientation. One of several potential wind estimation 
maneuvers could be completed during descent and incorporated into the guidance and 
control algorithms. These methods are designed to measure and adjust to a continually 
changing wind profile during platform descent and offer precision that an airspeed sensor 
is unlikely to provide in a low-speed dynamic flight envelope. 

4. Improved Parachute Design 

This research effort commenced with the objective of assessing the potentially 
enhanced maneuverability of elliptical ram-air parachutes with regard to micro-light 
weight class PADSs. Unfortunately, the manufacturing quality of the elliptical parachutes 
was not sufficient to support experimentation. However, the question remains as to 
whether the elliptical parachutes can offer greater maneuverability and the potentially 
resultant increase in terminal accuracy. If a ram-air parachute becomes available, the 
Snowflake ADS is still a viable test platform to support more exhaustive examination of 
its flying qualities. 
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5. Incorporation of an Imaging Sensor 

Previous versions of the Snowflake ADS had limited integration of a monocular 
vision sensor to assist in the acquisition of a non-cooperative mobile target and 
navigation in the GPS-denied environment. Unfortunately, the author was not able to 
incorporate a vision sensor, due to the late transition to the X-Monkey platform. Though 
an imaging sensor could assist in the terminal phase of a precise delivery for a mobile 
target, it could also assist in pose estimation in a GPS denied or degraded environment. 
As such, the incorporation of an imaging sensor does potentially increase the 
technological and cost complexity past the threshold for operational feasibility for a 
micro-light weight class PADS. Notwithstanding, the concept is still potentially viable to 
augment terminal accuracy for larger PADSs that are not considered to be single use 
items, especially in the GPS denied environment. 
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APPENDIX. MATLAB SCRIPTS 


A. FUNCTION TO CONVERT SENSOR DATA TO BODY FRAME 

This function was used multiple times in analysis of both laboratory experiments 
and flight data to convert the Euler orientation of the X-Monkey sensor to a more useful 
Euler orientation of the Snowflake. 


function [SFeul] = XMeul2SFeul(eul) 

%This function accepts user input of a [1x3] vector of Euler angles in 
%degrees. Input Euler angles [roll pitch yaw]. This rotates the Euler 
%angles output from X-Monkey to the Snowflake orientation. Use to 
%convert raw X-Monkey data to generate flight profile of SF. Since X- 
%Monkey outputs roll in 0—360, and yaw in 0—360, this function wraps 
%the data to roll=+/-180 and yaw=+/-180 for computation. Output wraps 
%the yaw to 0—360 for heading output. 

eul=wrapTol80(eul); 
qM_I=eul2quat(eul); 
qI_S=[0.5 0.5 0.5 -0.5]'; 
qM_S=q_mult(qM_I,qI_S); 

SFeul(1)=atan2(2 *(qM_S(3)*qM_S(4)+qM_S(1)*qM_S(2)), 
(l-(2*(qM_S(2)"2+qM_S(3)"2)))); 

SFeul(2)=-asin(2*(qM_S(2)*qM_S(4)-qM_S(l)*qM_S(3))); 

SFeul(3)=atan2(2 *(qM_S(2)*qM_S(3)+qM_S(1)*qM_S(4)), 
(l-(2*(qM_S(3)"2+qM_S(4)"2)))); 

SFeul=rad2deg(SFeul); 

SFeul(3)=wrapTo360(SFeul(3)); 
end 

B. SCRIPT TO ANALYZE LABORATORY ORIENTATION EXPERIMENTS 

This script was used to rotate, analyze and confirm the correct orientation of the 
Euler data recorded by the X-Monkey to the more appropriate Snowflake frame for use in 
subsequent flight-testing. It utilizes the Euler angle conversion function created 
separately. 


% Snowflake X-Monkey Data Processing 
close all; clear all; clc; 

%% Read in the data file you want to process that include YMDHM 
%sequence: 
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%Note: This takes an X-Monkey CSV file which must be generated using 
%the PARSR Program. Add the 4-digit year to the beginning of the data 
%file name. 

[filename, pathname] = uigetfile ('*. csvChoose First X-Monkey data 
file' ); 

FileName = [pathname filename]; 
iD=strfind(filename, '201' ); 

YY=str2num(filename(iD:iD+3)); Mo=str2num(filename(iD+4:iD+5)); 

DD=str2num(filename(iD+6:iD+7)); HH=str2num(filename(iD+8:iD+9)); 
Mi=str2num(filename(iD+10:iD+11)); 

DateNumberO=datenum(YY,Mo,DD,HH,Mi,0); 

Datestring = datestr(DateNumberO); 

File = csvread(FileName,1,0); 

choice = questdlg( 'Would you like to enter another file from this 
experiment?' , 'Additional Files' ); 

YN=strcmp(choice, 'Yes' ); 

while YN == 1 

[filename, pathname] = uigetfile ('*. csvChoose Another X-Monkey 
data file' ); 

FileName = [pathname filename]; 

File = vertcat(File,csvread(FileName,1,0)); 

choice = questdlg( 'Would you like to enter another file from this 
experiment?' , ... 

'Additional Files'); 

YN=strcmp(choice, 'Yes' ); 

end 

eul=[File(:,28) File(:,29) File(:,30)]; 

[M, N]= size(eul); 

SFeul = zeros(M,N); 
for i=l:M 

SFeul(i,:)=XMeul2SFeul(eul(i, :)) ; 
end 

%% Create Plot of X-Monkey Roll, Pitch, and Yaw 
figure(1) 
subplot(311) 

plot(File(:,5),File(:,28)) 
title (' X-Monkey Euler Angles'); 
ylabel('Roll ("o)'); 
axis tight 

subplot(312) 

plot(File(:,5),File(:,29)) 
ylabel( 'Pitch ("o)' ); 
axis tight 

subplot(313) 

plot(File(:,5),File(:,30)) 
ylabel('Yaw {^o)'); 
xlabel('Time (s)'); 
axis tight 
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%% Create Plot of Roll, Pitch, and Yaw 
figure(2) 
subplot(311) 

plot(File(:,5),SFeul(:,1) ) 
title (' Snowflake Euler Angles'); 
ylabel('Roll ("o)'); 
axis tight 

subplot(312) 

plot(File(:,5),SFeul(:,2)) 
ylabel( 'Pitch ("o)' ); 
axis tight 

subplot(313) 

plot(File(:,5),SFeul(:,3)) 
ylabel('Yaw {^o)'); 
xlabel( 'Time (s)'); 
axis tight 

%% Create Euler Rate Plots 
figure(3) 
subplot(311) 

filterroll=medfiltl(-File(:,37),500); 
plot(File(:,5),-File(:,37) ) 
hold on 

plot(File(:,5),filterroll, 'r' , 'LineWidth' ,2) 
title (' Snowflake Roll, Pitch, and Yaw Rates'); 
legend( 'Raw Sensor Output ',' Filtered Sensor 
Output' , 'Location' , 'northwest' ); 
ylabel('Roll rate {^o/s)'); 
axis tight 
hold off 

subplot(312) 

filterpitch=medfiltl(File(:,35),500 ) ; 
plot(File(:,5),File(:,35) ) ; 
hold on 

plot(File(:,5),filterpitch, 'r' , 'LineWidth' ,2); 
ylabel( 'Pitch rate {^o/s)'); 
axis tight 
hold off 

subplot(313) 

filteryaw=medfiltl(-File(:,36),500); 
plot(File(:,5),-File(: ,36)) ; 
hold on 

plot(File(:,5),filteryaw, 'r' , 'LineWidth' ,2); 

ylabel('Yaw rate {^o/s)'); 

xlabel('Time (s)'); 

axis tight 

hold off 
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c. 


SCRIPT TO MERGE X-MONKEY .CSV FILES TO SINGLE .MAT FILE 


This script was used to combine the series of .csv files that were outputted by the 
X-Monkey. Due to some hardware limitations internal to the X-Monkey, each output data 
file is only 7Mb. Following the experiment, the series of .csv fdes can be merged to a 
single .mat file to speed up analysis. 


%% Script for merging multiple .csv files into a single.mat file 
% First redefine the YYYYMMDDSF(#)D(Drop#).mat file at the end 
% Import any number of .csv files, creates .mat file 
% Move .mat file to appropriate folder 

close all; clear all; clc 

[filename, pathname] = uigetfile ('*. csvChoose First X-Monkey data 
file' ); 

FileName = [pathname filename]; 
iD=strfind(filename, '201' ); 

YY=str2num(filename(iD:iD+3)); Mo=str2num(filename(iD+4:iD+5)); 

DD=str2num(filename(iD+6:iD+7)); HH=str2num(filename(iD+8:iD+9)); 
Mi=str2num(filename(iD+10:iD+11)); 

DateNumberO=datenum(YY,Mo,DD,HH,Mi,0); 

Datestring = datestr(DateNumberO); 

File = csvread(FileName,1,0); 

choice = questdlg( 'Would you like to enter another file from this 
flight? ', 'Additional Files'); 

YN=strcmp(choice, 'Yes' ); 

while YN == 1 

[filename, pathname] = uigetfile ('*. csv ',' Choose Another X-Monkey 
data file' ); 

FileName = [pathname filename]; 

File = vertcat(File,csvread(FileName,1,0)); 

choice = questdlg( 'Would you like to enter another file from this 
flight? ', 'Additional Files'); 

YN=strcmp(choice, 'Yes' ) ; 

end 

save 20160219SF4D3.mat % Name .mat output file here 

D. SCRIPT TO ANALYZE X-MONKEY FLIGHT TEST DATA 

This script uses the .mat fde created earlier to process that data and produce a 
series of graphs to analyze the flight profile. 

%% Snowflake X-Monkey Data Processing using a .mat file 
% This script uses a full .mat file from the flight 
% User selects full flight file and processes accordingly 
% CSV version merges the files and then processes 
% To use this version, run the MergeFiles.m script once and 
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% Save the .mat file in the correct directory 


close all;clear all;clc; 

[filename, pathname]=uigetfile ('* .matChoose X-Monkey .mat file'); 
fname=fullfile(pathname,filename); 
load(fname); 

%% Set Variables 
Servo0neutral=1491; 

Servolneutral=1508; 

%% Set Location 

testsite= 'McMillan Airfield, Camp Roberts, CA' ; 

%% Calculate Snowflake Release and Parachute Deployment 
Tskip=0; 

%[maxAlt,IndAlt]=max(File(:,22)); %Use GPS Altitude 

[maxAlt,IndAlt]=max(File(:,52)); %Use Baro Altitude 

Tskip=Tskip+IndAlt; 

disp([' Release altitude ' num2str(maxAlt,3) ' m' ]) 

% Use total acceleration to find launch, release and land 
% View Figure (1) to determine what exact peaks represent and adjust 
% Smaller data files may not have all three events 
% Cross reference with altitude plots as well 

Acceltot=sqrt(File(:,32)."2+File(:,33)."2+File(:,34)."2); 

[pks,locs] = findpeaks(Acceltot, 'MINPEAKHEIGHT' , 

40, 'MinPeakDistance' ,1000); 

T20Launch=locs(1) ; 

SFChuteDeploy=locs(2 ) ; 

SFLand=locs(3 ) ; 

%T20Launch=locs(2); 

%SFChuteDeploy=locs(3); 

%SFLand=locs(4); 

ReleaseDelay=100*5; % Five second after release 
LandCutoff=100*3; % Three seconds prior to ground impact 

%ChuteOpenAlt = File(SFChuteDeploy,22); %GPS Altitude 
ChuteOpenAlt = File(SFChuteDeploy,52); %Baro Altitude 
%LandAlt=File(SFLand,22); %GPS Altitude 

LandAlt=File(SFLand,52); %Baro Altitude 

DropProfile = File(SFChuteDeploy:SFLand,:); 

SSDropProfile=File(SFChuteDeploy+ReleaseDelay:SFLand-LandCutoff,:); 
AltRange = ChuteOpenAlt - LandAlt; 

DescentTime = File(SFLand,5)-File(SFChuteDeploy,5); 

%% Convert X-Monkey Euler Angles to Snowflake Euler Angles 
eul=[SSDropProfile(:,28) SSDropProfile(:,29) SSDropProfile(:,30)]; 
[M, N]= size(eul); 
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SFeul = zeros(M,N); 
for i=l:M 

SFeul(i,:)=XMeul2SFeul(eul(i,:)); 
end 

%% Create Birds-Eye View Plot 
figure(1) 
hold on 

plot(DropProfile(:,21),DropProfile(:,20), 'w-' ) 
plot(DropProfile(1,21),DropProfile(1,20), 'rs' ) 
plot(SSDropProfile(l,21),SSDropProfile(1,20), 'y*' ) 
plot(SSDropProfile(end,21),SSDropProfile(end,20), 'bp' ) 
plot(DropProfile(end,21),DropProfile(end,20), 'gd' ) 
plot_google_inap( 'MapType' , 'satellite' ) ; 

title({' Camp Roberts Bird''s-Eye View' ;testsite;DateString}); 
h=legend( 'Trajectory ',' Canopy Deployment ',' Steady State Begins',... 

'Steady State Ends ',' Touchdown ',' location ',' best '); 
set(h, 'fontsize' ,8); 

xlabel(' Latitude {^o)' ), ylabel(' Longitude {^o)' ) 
hold off 

%% Plot 3D Profile 
figure(2) 
hold on 

plots(DropProfile(:,21),DropProfile(:,20),DropProfile(:,52),'-'); 
plots(DropProfile(:,21),DropProfile(:,20),DropProfile(:,22),' — '); 
plots(DropProfile(1,21),DropProfile(1,20),DropProfile(1,52), 'rs' ) 
plots(DropProfile(1,21),DropProfile(1,20),DropProfile(1,22), 'rs' ) 
plots(SSDropProfile(1,21),SSDropProfile(1,20),SSDropProfile(1,52), 'y*' ) 
plots(SSDropProfile(1,21),SSDropProfile(1,20),SSDropProfile(1,22), 'y*' ) 
plots(SSDropProfile(end,21),SSDropProfile(end,20),SSDropProfile(end,52) 
, ' bp' ) 

plots(SSDropProfile(end,21),SSDropProfile(end,20),SSDropProfile(end,22) 
, ' bp' ) 

plots(DropProfile(end,21),DropProfile(end,20),DropProfile(end,52), 'gd' ) 
plots(DropProfile(end,21),DropProfile(end,20),DropProfile(end,22), 'gd' ) 

title({'Camp Roberts 3 Dimensional View' ;testsite;DateString}); 
legend( 'Barometric Altimeter' , 'GPS Altimeter' , 'Canopy Deployment 
(Baro)' , ••• 

'Canopy Deployment (GPS)' , 'Steady State Begins (Baro)' , 'Steady 
State Begins (GPS)',... 

'Steady State Ends (Baro )',' Steady State Ends (GPS)' , 'Touchown 
(Baro)' , 'Touchdown (GPS)' , 'Location' , 'best' ); 
xlabel(' Latitude 
ylabel(' Longitude {^o)'); 
zlabel( 'Altitude (m)' ); 
zlim([0 inf]) 
view(-28 ,21) 
grid 

hold off 

%% Plot Full Flight Profile 
figure(3); 
subplot(411) ; 
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plot(File(:,5),File(:,22),File(:,5),File(:,52)) 

title({'Full Altitude Profile' ;testsite;DateString}); 
ylabel( 'Altitude (m)' ); 

legend( 'GPS AltitudeBaro AltitudeLocationBest' ) 
axis tight 

subplot(412); 
plot(File(:,5),Acceltot) 
title ('Total Acceleration'); 
ylabel ( ' a_{xyz} (in/s'"2)'); 
axis tight 

subplot(413); 

plot(File(:,5),File(:,23)) 
title( 'GPS Ground Speed'); 
ylabel (' Ground Speed (m/s)'); 
axis tight 

subplot(414); 

plot(File(:,5),File(:,24)) 
title ('GPS Ground Track'); 
xlabel('Time (s)'); 
ylabel (' Degrees (""o)'); 
axis tight 

%% Create Plot of X-Monkey Roll, Pitch, and Yaw 
figure(11) 
subplot(311) 

plot(SSDropProfile(:,5),eul(:,!)) 

title ({' X-Monkey Euler Angles '; testsite;DateString}); 
ylabel('\phi {^o)'); 
axis tight 

subplot(312) 

plot(SSDropProfile(:,5),eul(:,2)) 
ylabel( '\theta ("o)'); 
axis tight 

subplot(313) 

plot(SSDropProfile(:,5),eul(:,3)) 
ylabel('\psi {^o)'); 
xlabel('Time (s)'); 
axis tight 

%% Create Plot of Snowflake Roll, Pitch, and Yaw 
figure(5) 
subplot(311) 

plot(SSDropProfile(:,5),SFeul(:,!)) 

title ({' Snowflake Euler Angles '; testsite;DateString}); 
ylabel('\phi {^o)'); 
axis tight 

subplot(312) 

plot(SSDropProfile(:,5),SFeul(:,2)) 
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ylabel ( ' \theta (""o) ' ) ; 
axis tight 

subplot(313) 

plot(SSDropProfile(:,5),SFeul(:,3)) 
ylabel('\psi {^o)'); 
xlabel( 'Time (s)'); 
axis tight 

%% Create Euler Rate Plots 
figure(6) 
subplot(311) 

frrate=medfiltl(-SSDropProfile(:,37),500); 
fprate=medfiltl(-SSDropProfile(:,35),500); 
fyrate=medfiltl(-SSDropProfile(:,36),500); 

plot(SSDropProfile(:,5),-SSDropProfile(:,37)) 
hold on 

plot(SSDropProfile (1,5), frrate , 'r ' , 'LineWidth ' ,2) 
title({' Roll, Pitch and Yaw Rates testsite;DateString}); 
ylabel (' $\dot{\phi} {^o/s)$'f 'Interpreterlatex' ) 

axis tight 

subplot(312) 

plot(SSDropProfile(:,5),SSDropProfile(:,35)) 
plot(SSDropProfile (1,5), fprate , 'r' , ' LineWidth ' ,2) 
ylabel( '$\dot{\theta} {^o/s)$' , 'Interpreter' , ' latex' ) 

axis tight 

subplot(313) 

plot(SSDropProfile(:,5),-SSDropProfile (:,36)) 
plot(SSDropProfile {:,5), fyrate , 'r' , 'LineWidth ' ,2) 
ylabel (' $\dot{\psi} {^o/s)$', 'Interpreterlatex' ) 

xlabel('Time (s)'); 
axis tight 

%% Create Acceleration Plots 
figure(7) 
subplot(311) 

plot(SSDropProfile(:,5),SSDropProfile(:,34)) 
title({ 'Accelerations' ;testsite;Datestring}); 
ylabel (' a_{x} (m/s'"2)'); 
axis tight 

subplot(312) 

plot(SSDropProfile(:,5),SSDropProfile (:,32)) 
ylabel (' a_{y} (m/s'"2)'); 
axis tight 

subplot(313) 

plot(SSDropProfile(:,5),SSDropProfile (:,33)) 
ylabel (' a_{z} (m/s'"2)'); 
xlabel('Time (s)'); 
axis tight 
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%% Create Control Input Plots 
figure(8) 
subplot(211) 
hold on 

plot(SSDropProfile(:,5),SSDropProfile(:,59), 'Color ' , 'r' ) 
hlineO=refline(0,ServoOneutral); 
set(hlineO, 'LineStyle' , '—' ); 

title ({' Control Line Inputs (Right )'; testsite;DateString}); 

ylabel (' Servo Zero Command (PWM)'); 

ylim([ServoOneutral-150 ServoOneutral+150]); 

hold off 

subplot(212) 
hold on 

plot(SSDropProfile(:,5),SSDropProfile(:,60), 'Color ' , 'r' ) 
hlinel=refline(0,ServoIneutral); 
set(hlinel, 'LineStyle' , '— '); 

title ({' Control Line Inputs (Left)' ;testsite;DateString}); 

ylabel (' Servo One Command (PWM)'); 

ylim([Servolneutral-150 Servolneutral+150]); 

hold off 

%% Compare Yaw Angle and Ground Track Plot 
figure(9) 
hold on 

plot(SSDropProfile(:,5),SFeul(:,3)) 

plot(SSDropProfile(:,5),SSDropProfile(:,24)) 

title({'Yaw Angle vs GPS Ground Track '; testsite;DateString}); 
ylabel (' Yaw/Ground Track {^o)'); 
xlabel('Time (s)'); 

legend( 'Magnetometer Heading ',' GPS Ground Track') 
axis tight 
hold off 

%% Three axis GPS velocity 
figure(10) 

hold on; 
subplot(311) 
hold on 

plot(SSDropProfile(:,5),SSDropProfile(:,25)) 
plot(SSDropProfile (1,5 ),SSDropProfile(:,26),' — ') 
title({'GPS Velocity Data '; testsite;DateString}); 
ylabel( 'V_{N;E} (m/s)' ); 

legend( 'V_{N}' , 'V_{E}' , 'Location' , 'best' ) 
axis tight 
hold off 

subplot(312) 
hold on 

plot(SSDropProfile(:,5),SSDropProfile(:,27)) 
plot([SSDropProfile(1,5) SSDropProfile(end,5)] 

,mean(SSDropProfile(:,27))*[1 l],'-.r'); 

text(SSDropProfile(1,5),mean(SSDropProfile(:,27)),[ 'mean V_{D} 
num2str(mean(SSDropProfile(:,27))) ' m/s' ]); 
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ylabel( 'V_{D} (m/s)' ); 
axis tight 
hold off 

subplot(313) 

VG=sqrt(SSDropProfile(:,25)."2+SSDropProfile(:,26)."2); mVG=mean(VG); 
hold on 

plot(SSDropProfile(:,5),VG) 

plot([SSDropProfile(l,5) SSDropProfile(end,5)] ,mVG*[l l],'-.r'); 

text(SSDropProfile(l,5),mVG,[ 'mean V_{G} = ' num2str(mVG) ' m/s']); 

ylabel( 'V_{G} (m/s)' ); 

xlabel('Time (s)'); 

axis tight 

hold off 
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